Makes EnvName mutable to avoid allocating it for lookups

[franz1981]

While working on #1294 I've discovered two interesting things:

• EnvName::hashCode (which is compute intensive) it's performed twice due to a mix of if get == null, put: here I've enabled hashCode caching, despite it makes EnvName a bit fatter i.e. 24 bytes vs 16 :"(
• EnvName is created multiple times on the fly, to perform matching - without ever storing it (!). And most of the times these are misses: I've than allow it to be mutable to avoid keeping on allocating them

[franz1981]

A similar effect with a smaller increment could be obtained via int[] cache of hash codes; we can still perform hash code computation directly on the String and using the int[] as a sort of bloom filter using a single hash function:

• if the check is positive we need to perform the allocation and go down the slow path of checking the map
• if the check is negative no need to further check

That depends by the collision of keys vs the given hash function, so the effect is potential reduction of allocations

[radcortez]

This can cause issues if not thread-safe. While we use a simple HashMap, we never modify it after creation.

[franz1981]

I can make #1295 (comment) once you apply your changes :P