Replace deprecated speech dictionary hooks with a compatibility bridge

[CaptainStormblade]

Summary

This PR updates Emoticons to work with both legacy and current NVDA speech dictionary APIs. It removes the deprecation-warnings seen on newer NVDA versions and prevents dictionary cleanup from delaying or interfering with NVDA termination.

Changes

• Add a capability-based speech dictionary compatibility bridge.
• Use NVDA's public filter_speechSequence extension point when available.
• Import SpeechDict, SpeechDictEntry, and EntryType from their new module on current NVDA versions while retaining a fallback for older versions.
• Keep a temporary-dictionary fallback for NVDA versions without the public speech filter.
• Make activation and deactivation idempotent so repeated profile switches and dialog operations cannot register duplicate hooks.
• Fail safely if no supported activation API is available, allowing NVDA shutdown to continue.

Testing

• Built the NVDA add-on successfully.
• Verified manually with a newer NVDA build that Emoticons still announces entries correctly.
• Verified that the previous speech dictionary deprecation entries no longer appear in the NVDA log.
• Ran python -m unittest discover -s tests -v: 3 tests passed.
• Ran python -m ruff check .: passed.
• Ran Python compilation and git diff --check: passed.

Compatibility note

On current NVDA versions, Emoticons applies its dictionary through the speech filter instead of adding entries to NVDA's Temporary Dictionary. The entries therefore no longer appear in NVDA's Temporary Dictionary dialog, but the add-on's own Emoticons dictionary dialog remains available.

[nvdaes]

Hello @CaptainStormblade
Thanks for your interest in this add-on.
In fact, I had planned to update this code according to changes introduced for dictionaries, though I hadn't planned to use filter speech sequences, what certainly may be a good idea.
I'd like to ask you some questions:

1. Seems that you haven't used the template provided for pull requests on this repo. Can you clarify if is there any reason for this?
2. Have you tested if this works properly by using different dictionaries for different profiles?
3. Generally, unless this doesn't imply no eforz at all, I prefer not to work to maintain compatibility with previous versions of NVDA, to keep the code as readable and maintainable as possible, considering that, using the store, compatible version of add-ons will be presented. So, if we declare the minimum tested version to be 2026.2, people using NVDA 2026.1 won't see this add-on in the store. Can you remove code used to keep the add-on compatible with previous versions?
4. Can you write a changelog for this, in buildVars.py?
   Thanks in advance.

[nvdaes]

@CaptainStormblade , unless you provide the required info, I'll close this PR.
Hopely this has been submitted by a human. I don't want pull requests submitted by AI bots.

[nvdaes]

The requested info was not provided.