FieldLayoutSchemeImpl caching is not thread-safe

FieldLayoutSchemeImpl.java has a number of thread-safety issues. Firstly it uses a HashMap as its cache and does not synchronise access or mutable operations. Fortunately it doesn't get mutated very often so we don't see problems with this very often.

Worse is that it suffers from a race-condition at startup, where it is lazily initialised. This initialisation depends on the nullness of the schemeEntities reference, but other threads can see a partially initialised schemeEntities cache, which if it doesn't have the default entry in it yet leads to the following:

[webwork.util.ServletValueStack] METHOD: "fieldHidden", exception:
java.lang.NullPointerException
        at com.atlassian.jira.issue.fields.layout.field.FieldLayoutSchemeImpl.getFieldLayoutId(FieldLayoutSchemeImpl.java:107)
        at com.atlassian.jira.issue.fields.layout.field.enterprise.EnterpriseFieldLayoutManager.getFieldLayout(EnterpriseFieldLayoutManager.java:73)
        at com.atlassian.jira.web.bean.FieldVisibilityBean.isFieldHidden(FieldVisibilityBean.java:163)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...

Also, the access to the schemeEntities reference itself is not safe, so it is possible multiple threads could be initialising multiple schemeEntities maps.

Please note that null has a special value in this map, so ConcurrentHashMap is not a drop-in replacement, and doesn't fix the visibility and unsafe publication problems.