The `orderMap` field was removed as it was only responsible for maintaining the insertion order of timer IDs. This is
now accomplished more cheaply by changing `timeMap` to `LinkedHashMap<>`. This saves some extra hash table reads and
writes, and also means we don't need to explicitly sort IDs during reporting.

There were a couple places where we did redundant key lookups on `timeMap`, to handle cases where the key may or may not
already exist. These were modified to instead do a single key lookup, via `computeIfAbsent()` and `get()`.

This is inspired by loggers, though based on `String.format()`. It allows using timers with dynamic names without
needing to clutter calling code with `CodeTimer.isEnabled()` checks to avoid the overhead when not needed.

The few places that used `CodeTimer.isEnabled()` for this purpose have been updated to use the parameterized form, and
`isEnabled()` is now only used to check if timings should be reported.

Each thread has a stack of `CodeTimer`, with the top of the stack being available anywhere via a call to
`CodeTimer.get()`. When a different timer is needed for a section of code, `CodeTimer.using()` will push a new timer
onto the stack, and pop it off the stack when the timed code completes, restoring the previous timer.

`CodeTimer.using()` also takes care of enabling the new timer based on `AppState.isCollectProfilingData()`, and
reporting the results at the end if the timer is enabled. This saves some repeated logic and adds a bit of consistency
in how timers are used.

All affected components followed the same basic pattern, with some variations:
1. Create the timer.
2. Enable / disable the timer, usually based on AppState.
3. Set a minimum threshold.
4. At the end, report to the profiling frame.

Now (1), (2) and (4) are done automatically and consistently in `CodeTimer.using()`, with (2) and (3) also doable by the
caller to customize the timer as needed.