Consolidate experimental feature enablement

[strassek]

As the project grows so too does the number of optional build flags that are used to selectively enable / disable experimental features or behaviors. This pattern causes maintainability issues for two reasons. First, any code that isn't being built by default will likely be left behind as our internal APIs change over time. Second, it becomes difficult for any one person to understand what experimental features are available, how they can be enabled, and what (if any) platform and hardware dependencies they require.

In effort to rein in this situation, I suggest we consolidate runtime feature enablement to a single registry, and require that all new experimental features use that registry instead of a build flag or otherwise ad-hoc enablement mechanism. Over time we can move the existing experimental features to use this new mechanism.

Inspiration for this idea comes from 'chrome://flags' in Chrome browser.

We may also want to consider having a single 'hardened' build mode that
completely disables experimental features.

Requirements:

• Native enablement mechanism for each supported platform, i.e. property_get() on Android and std::getenv() for generic Linux. Make sure to namespace all exposed options.

• Expect to latch to options as they are configured before init. Toggling options during runtime would have no affect until the next time IAHWC initializes.

• Enumerate every option in once place (registry), that is also where we would specify if an option is platform / hardware specific.

• Port at least one existing feature to use the new mechanism.