Jinjava 3.0: Roll back some of the unnecessary breaking changes

[jasmith-hs]

There can be some binary incompatibility issues with how I migrated JinjavaConfig to an immutable and LegacyOverrides to an Immutable.

• The JinjavaConfig migration binary incompatibility can be solved by having JinjavaConfig remain a class so that the reference to JinjavaConfig#newBuilder remains a class method reference rather than an interface method reference.

• I could not keep LegacyOverrides as an immutable, and had to revert it back to being a POJO. Trying to solve the interface method reference backwards incompatibility issue by making it a class could introduce a static class initialization deadlock due to the static members like LegacyOverrides.NONE referencing a subclass of LegacyOverrides (ImmutableLegacyOverrides)

• I kept it so that eager execution will continue to reconstruct the JinjavaInterpreter arguments as ____int3rpr3t3r____ rather than null so that if needing to revert an upgrade to Jinjava 3.0, there won't have been any first-phase eager execution outputs that are backwards incompatible (as resolving null for exptests and filters in Jinjava 2.8.X would break them). This does not decrease the security of Jinjava 3.0 because I'm still not resolving the ____int3rpr3t3r____ variable ever, it is still resolved to null