Added a way for "geyser_custom" blocks to be recognized by the reader.

[OmeWillem]

Title says it all.

[duranaaron]

+1, I would really like this to be implemented as well

[OmeWillem]

Any news on this being merged maybe?

[onebeastchris]

I'm unsure whether this is, right now, a good API addition. Few issues:

• This PR is currently wholly undocumented, which for API is generally terrible

• This PR makes use of code - mainly the NonVanilaCustomBlockData class - that has an initially different purpose, hence there's some behaviour that wouldn't be triggered for it (which would be for CustomBlockData itself).
  That's not necessarily a blocker, but this PR lacks any description of e.g. an example mapping/usage that's possible with this change that isn't possible without it.

• As mentioned above - it would be ideal if there would be a provided mapping example, with a clear description of what this PR enables (and what isn't possible without it). That way, we can properly test and review it, and account for this behaviour when we eventually refactor code. As an example, see Fix: Allow adding custom items to the creative item list to allow custom recipes to show up in the recipe book #4484 :)

In short - we're open to add features and are thankful for PRs. However, we'll need more details on what this enables doing that's not possible without it, so we can properly account for it when reviewing / when refactoring code in the future / when considering API design in a potential V2 :)

(final note - what's that collision check for? Does that issue still occur with the latest version of Geyser that registers collisions for custom blocks?)