Thread-safe block and item type ID assignment

[dktapps]

I realised the PR #6786 was trying too hard to avoid sharing any data between threads, but it looks like the performance impact of trying to do so is much greater than the performance impact of just sharing ID registration tables.

A new method of claiming type IDs has been implemented. Using a string unique to the block type, such as the block's Minecraft string ID, blocks can ensure they always get to claim the same ID on all threads. This ID is not guaranteed to be the same across different runs, but it at least permits moving block and item type/state IDs across threads without ridiculous serialization hacks.

There may be other places where we could benefit from a system like this. Basically anywhere plugins might need to fight over ID assignment.

Checks have also been added to ensure that plugins can't just use a random unassigned type ID, as this may cause conflicts with other plugins. This isn't foolproof, but we can't do better than this without breaking BC and stopping plugins from providing numeric type IDs entirely (thereby stopping them from being hardcoded).

Related issues & PRs

• fixes BlockTypeIds::newId() is not synchronized between threads #6062

Changes

API changes

• added BlockTypeIds::claimId() and BlockTypeIds::getClaimant()
• added ItemTypeIds::claimId() and ItemTypeIds::getClaimant()
• deprecated BlockTypeIds::newId() and ItemTypeIds::newId()
• added new ThreadSafeSingletonTrait

Behavioural changes

Unless plugins use these new APIs, none are expected, bar some deprecation notices.

Follow-up

BlockIdentifier and ItemIdentifier to accept strings directly instead of ints (and have numeric type IDs internally claimed)

Tests

tests are green