add feature flags to jinjava config

[boulter]

When building #1065, I didn't like adding yet another property to the JinjavaConfig builder. I figured we could use a simple Feature Flags implementation.

Partially inspired by https://ff4j.org/ and https://www.togglz.org/ .

This can replace any boolean configs like enablePreciseDivideFilter, enableRecursiveMacroCalls, failOnUnknownTokens, nestedInterpretationEnabled and more in the future.

[jasmith-hs]

This is definitely more sustainable than the current approach, and it lets you define features for extensions of Jinjava!

[jasmith-hs]

I think DisabledFeatureActivationStrategy, DelegatingFeatureActivationStrategy, and StaticFeatureActivationStrategy are redundant implementations as you can use a lambda:

FeatureConfig
.newBuilder()
.add(name1, () -> false)
.add(name2, () -> true)
.add(name3, supplier)

[boulter]

Agreed. I wanted some simple and standard way to get strategies that were always or off. I removed those classes and added some static delegating strategies instead.

[jasmith-hs]

The DelegatingFeatureActivationStrategy boilerplate can be removed too

[boulter]

Done and also isActive now gets Context objects so it can make decisions based on other data that's in there, perhaps a user or customer userid.

[jasmith-hs]

Suggested change

	publicstaticfinalFeatureActivationStrategyINACTIVE = DelegatingFeatureActivationStrategy.of(
	() -> false
	);
	publicstaticfinalFeatureActivationStrategyACTIVE = DelegatingFeatureActivationStrategy.of(
	() -> true
	);
	publicstaticfinalFeatureActivationStrategyINACTIVE = () -> false;
	publicstaticfinalFeatureActivationStrategyACTIVE = () -> true;

[jasmith-hs]

The DelegatingFeatureActivationStrategy boilerplate can be removed too