See base PR #13851
Adds support for multi value feature flags from PR #13871

### Summary:
NVDA increasingly makes use of feature flags to expose experimental changes to users.
There are already several approaches already in use.
It is easy to miss use-cases for changing default behavior, potentially overriding an advanced users preferred config.

Some feature flags require more than just a Boolean enabled/disabled outcome (in addition to 'default'), E.G.:
- AllowUiaInMSWord [WHEN_NECESSARY, WHERE_SUITABLE, ALWAYS]
- AllowUiaInChromium [WHEN_NECESSARY, YES, NO]

Several approaches have been tried:
- Store an int in the config that match with enum values, as per (AllowUiaInMSWord and AllowUiaInChromium)
- Use "options" in config (several string values). Literal strings in code to compare refer to these.

These approaches can hide errors:
- Looking at the config, what are the valid values when an integer is used.
- Using string "options":
  - What are the valid options?
  - How do you find all usages?
  - Change the strategy for default?
- For both, when looking at the config or configSpec, how can the behavior of default be determined?

### Description of user facing changes
The target user of this change are developers.
This introduces constructs and utilities to streamline the approach to adding feature flags.

Adding a new feature flag:
- Most feature flags can use the BoolFlag.
- If more values are required, define a new enum class in featureFlagEnums.py (include a DEFAULT member) E.G.: MyNewFeature
- Add the entry to the configSpec.py E.G.
  shouldUseMyNewFeature = featureFlag(optionsEnumClass="MyNewFeature", behaviorOfDefault="ON_WEEKENDS")
- Add a GUI option for it, using FeatureFlagCombo
- Wrap the code for the feature with:
   config.conf["section"]["shouldUseMyNewFeature "] == MyNewFeature.ON_WEEKENDS

### Development approach
Introduction of a generic BoolFlag type (enabled/disabled) which needs to account for 3 states:
- The current NVDA default (IE user has no preference)
- User has a preference of enabled
- User has a preference of disabled

To facilitate this, one of the three values (default, enabled, disabled) is stored in the config.
Spec/config transformations are provided to streamline the support.
A featureFlag type in the spec is automatically converted to a FeatureFlag class instance.
The FeatureFlag class abstracts the consideration of "default", allowing the FeatureFlag to treated as a boolean within internal NVDA logic.

A utility GUI control is added which presents the FeatureFlag option to the user, and allows developers to give translated names to the logical values (enabled, disabled), the name for default incorporates the behaviorOfDefault (and is also translated).

Note:
- The configSpec explicitly defines what the behavior of default is.
- The enum class that backs the config is defined, allows for type / value checking.
- Existing flags have not been upgraded, these would require upgrade code for the config, this introduces unnecessary complexity.

### Known issues:
This approach bypasses the handling for defaults provided by configObj.
It was considered whether the default not written on read behavior (of the configObj library) to facilitate the third (default) state.
However:
- This would require explicit code to test for the existence of the key to know if the value returned by `conf["section"]["myKey"]` was just the default or an explicit setting.
- It also requires careful diligence to ensure that the value is not ever written accidentally.
- Code to delete the key is required whenever attempting to return to the default.
- The way validation checks are created in `configObj` makes transforming the type (to provide an abstraction) difficult. It is not possible to get access to the `default` without a similar approach used in this PR. If adopting the complexity of a spec and config transform step, then it is preferable to have explicit values for default. Explicit values make the config easier to inspect and make the approach more robust.