Bind ItemTypes constants to explicit ids instead of field order

ItemTypes resolved each of its constants by reading its own field list
reflectively and lowercasing the field name at the matching index.
Class.getDeclaredFields() explicitly does not specify an order, so this
depended on undefined behaviour; a sentinel static block was the only
thing standing between a reordered array and every constant silently
bound to the wrong item.

Each constant now calls the existing get(String) lookup directly with its
namespaced id, which is also the scheme upstream WorldEdit already uses.
Field order carries no meaning, so the sentinel block, the
fieldsTmp/initIndex state, the reflective walk, and the intermediate
init(String) wrapper are all gone.

Forcing ItemTypesCache to initialise moves into a static block above the
constants, since only its position relative to them matters. That removes
the lazy fieldsTmp == null check that previously guarded the one-time
call.

Reconcile the constant list with upstream while here. FAWE had fallen 19
constants behind: BLACK_HARNESS, BLUE_HARNESS, BROWN_HARNESS, CYAN_HARNESS,
DRIED_GHAST, GRAY_HARNESS, GREEN_HARNESS, HAPPY_GHAST_SPAWN_EGG,
LIGHT_BLUE_HARNESS, LIGHT_GRAY_HARNESS, LIME_HARNESS, MAGENTA_HARNESS,
MUSIC_DISC_TEARS, ORANGE_HARNESS, PINK_HARNESS, PURPLE_HARNESS,
RED_HARNESS, WHITE_HARNESS, and YELLOW_HARNESS are all declared upstream
and were missing here. No constant existed in FAWE that upstream lacks, so
nothing was removed. The declarations are now identical to upstream's
1,546.

Every id is "minecraft:" + the lowercased field name, matching both what
the previous scheme produced and what upstream declares, so the resolved
values are unchanged for every constant that survives.

Author: MattBDev