Make feature flag contract compatible with Statsig

[Chris Fuller]

Personally, I really like the convention of using the hosting class's fully-qualified class name, a ., and the constant name for the feature flag's key. Unfortunately, this pattern is starting to cause problems as Atlassian internally migrates to Statsig, as the flags are not permitted to contain . characters.

So the plan here is to migrate away from using bare strings and instead compose the feature key from a class and arbitrary suffix in a way that will comply with these rules. So a feature flag currently declared like this:

        public static final String ALLOW_LISTS = BlockquoteParser.class.getName() + ".ALLOW_LISTS";

will change to this:

        public static final FeatureFlag ALLOW_LISTS = new FeatureFlag(BlockquoteParser.class, "ALLOW_LISTS");

and the FeatureFlag constructor will do the appropriate munging to make this use the value "com-atlassian-adf-wiki-parser-tokenize-BlockquoteParser-ALLOW_LISTS" instead.

This change needs to be managed very carefully, because some of the feature flags that already exist (such as BlockquoteParse.ALLOW_LISTS itself) are already actively being used to roll out new editor features. The change should happen when things are relatively quiet so the change to the names of all the keys won't matter.

But it needs to happen before the transition to Statsig is finished!

[Chris Fuller]

It's possible to do part of the work up front here by introducing FeatureFlag without the string munging to get the new SPI contract in place and add the string munging later when we're ready to make the switch.

[Chris Fuller]

Fixed in 0.38.0.

Note that this is a breaking change for the FeatureFlagProvider SPI.