CFileNameManager以外の TSingleton を TSakuraSingleton に移行する

[berryzplus]

CFileNameManager以外の TSingleton も移行しておいたほうが良さげ。

Originally posted by @berryzplus in #2533 (comment)

サクラエディタが一部で状態依存のオブジェクトをシングルトン扱いにしてしまってる問題に対して、使えなくなった時点でリセットできるシングルトンオブジェクト TSakuraSingleton を導入した。

現状テストで動いている範囲では問題が起きていないが、単純に「全体の半分もテストできていない」に起因する事象と思われるので、どこかで対策を入れたい。

[berryzplus]

TSingleton派生クラスは11件あります。

Copilotに調査させたところ、TSakuraSingleton へ移行が必要なのは 4 件と言われました。

クラス	判定	理由
CAppNodeManager	不要	m_pShareData を保持せず、共有メモリは都度 GetDllShareData() で取得しているため、共有メモリ寿命に縛られない。
CCodeChecker	要	CDocListenerEx 派生で、ドキュメント生成時にインスタンス化される。ドキュメント生成開始後から破棄までの寿命に合わせるべき。
CAppMode	要	CDocListenerEx 派生。さらに状態を InitDoc() で都度リセットしており、実質的にドキュメント寿命依存の状態を持つ。
CJackManager	要	m_pShareData をメンバー保持し、コンストラクタで共有メモリをキャッシュしている。CFileNameManager と同系統の問題。
CPluginManager	不要	m_pShareData を保持せず、CDocListener でもない。共有設定参照は都度取得。
CFigureManager	不要	図形戦略の所有のみで、共有メモリ保持・ドキュメント監視なし。
CEditApp	不要	1プロセス1個のアプリ管理オブジェクトだが、m_pShareData 保持も CDocListener 継承もない。今回の移行基準には該当しない。
CColorStrategyPool	不要	ビュー/色分け戦略の管理で、共有メモリ保持・ドキュメント監視なし。
CMacroFactory	不要	マクロ生成器の登録管理のみ。共有メモリ保持・ドキュメント監視なし。
CDiffManager	不要	bool 状態のみを持つ軽量管理で、共有メモリ保持・ドキュメント監視なし。
CModifyManager	要	CDocListenerEx 派生で、ドキュメント生成時にインスタンス化される。ドキュメント寿命に合わせるべき。

CEditAppもリセットできないと困るような気がするんですけどね。

一応、「以下の評価観点に該当するものだけを移行」の指示に従えば間違ってなさそうにも思うわけで。

• メンバー変数 m_pShareData を持つものは共有メモリ依存なので移行が必要。
• CDocListner派生クラスはドキュメント依存なので移行が必要。

[berryzplus]

移行不要の7件について人力で再評価してみました。

クラス	判定	理由
CAppNodeManager	→ 要	共有メモリ上の「編集ノード」にアクセスするので、共有メモリと共に滅ぶのが自然。
CPluginManager	→ 要	アプリ終了時に登録済みプラグインを破棄する処理があるので、アプリと共に滅ぶのが自然。
CFigureManager	→ 要	設定（≒共有メモリ）と同期しているので、共有メモリと共に滅ぶのが自然。
CEditApp	→ 要	名前通り「アプリそのもの」を表すクラスっぽいので、アプリと共に滅ぶのが自然。
CColorStrategyPool	→ 要	設定（≒共有メモリ）と同期しているので、共有メモリと共に滅ぶのが自然。
CMacroFactory	→ 要	アプリ終了時に登録済みマクロ生成器を破棄する処理があるので、アプリと共に滅ぶのが自然。
CDiffManager	不要	実態として何も管理してないのでスルー可。

CEditAppについては #2542 で対応済み。

既存テストに影響が出るのはマクロとプラグイン。
カバレッジ向上の施策と衝突するのが図形と色。
何度か挑戦してるけど対応難易度が異常に高いのが編集ノード。

DiffマネージャーはCAppModeあたりと統合して廃止でよいかも。
（Diffマネージャー周辺は整理されてるので比較的ラクに廃止できる。）

結論として、全部移行しないとダメっぽい、の雰囲気に。