fix thread safety issue with nested column global dictionaries

[clintropolis]

Description

Fixes a pretty good blunder I made which resulted in the FixedIndexed implementations used by the nested columns not be thread safe, leading to undefined behavior when multiple readers are accessing the nested column global dictionaries at the same time. My intention was that FixedIndexed was using the positional read methods of TypeStrategy, so it should be thread-safe, however, the TypeStrategy employed here were not actually overriding these methods, so it was falling back to a positional read that sets the buffer position, reads, and then resets to the original position, which is most unchill in this scenario.

In addition to implementing these methods for long/double/int strategies being used here, I also made a change to switch nested columns to use FixedIndexed in a supplier, to save heap footprint per #12277 (comment). This change also would have made it thread safe had I not overridden these methods of TypeStrategy since the lazy creation of FixedIndexed now happens per thread.

I added a more direct test on NestedDataColumnSupplier, which was prior to this PR only tested indirectly through native and SQL query tests, to perform basic selector and bitmap index operations, and included a concurrent read test. The concurrency test failed consistently prior to the changes in this PR, but i ran on repeat ~200 times after the changes with no failures.

Release note

Fixes a bug with concurrent reads of nested columns with numeric global value dictionaries which could lead to undefined behavior when returning or filtering on nested numeric values.

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• been tested in a test Druid cluster.