給非組字選字模式引入關聯詞語（舊稱「聯想詞」）功能。

[ShikiSuen]

該功能與小麥注音 PR412 不同的是：威注音對該功能的實作不會用到組字引擎。

小麥注音的這個功能用著雖然方便，但會因為這個功能「無法搞清楚破音字的讀音該取哪個音」而導致一個問題： ...部分使用者在組字區內用過這個功能之後，組字區內可能出現實際上讀音不正確的音。 然後再就地標記加詞的話，使用者辭典內就會出現錯誤資料。

於是呢，關聯詞語這種東西本來就應該是脫離這種組字引擎、直接遞交到客體的。

本文所述「前」「後」乃是從文字書寫方向上的「前方」與「後方」。

威注音這邊目前的實作大致如下（假設關聯詞語模式開關處於開啟狀態、且組音區/組筆區是空的）：

• [x] IMEState.ofInputting() 會在傳入 Shift+Enter 按鍵事件的時候：
  • 先記下當前組字區（文字輸入方向上的）最前方的字詞節點（簡稱「前方節點」）；
  • 再照常遞交當前組字區；
  • 最後，在符合條件的情況下，叫出關聯詞語選字窗。
• [x] IMEState.ofCandidates() 會在傳入 Shift+Enter 按鍵事件的時候：
  • 先記下當前高亮候選字詞，檢查「游標是否在文字輸入方向上的最前方」且「有無關聯詞語資料可用」。
  • 兩個條件都無法同時滿足的話，則僅確認當前候選字。
  • 兩個條件都滿足的話，確認候選字＋遞交當前組字區＋叫出聯想詞選字窗。

至於小麥注音在聯想詞功能當中可能有的其他特性沒被威注音實作的原因：

• 目前 InputMethodKit 對客體編輯器內的「游標位置直接指定」實作有難度，且實作效果受制於客體自身的行為、不可控。
  • 所以也就無法可靠地實作「遞交後、讓客體應用的游標位置變成『在遞交之前的組字區內的游標位置』」這個功能特性。
  • 同理：IMEState.ofCandidates() 選字模式下對該功能的驅動選擇也受制於該現狀。
  • 但或許可以在當前游標為最前方的時候實作該特性。

[ShikiSuen]

Done. CheatSheet 也做了更新。