Add Vault block API

[Warriorrrr]

Supersedes #11159

Adds new API for vault blocks

Changes made compared to the previous PR:

• Added some javadocs.
• Removed itemsToEject methods, these items are only populated when a player is opening a vault, but these can already be changed with the block dispense loot event, and also can't think of any use case for changing items in the middle of ejecting.
• Removed rewarded players methods with player instances.
• Added API for state update time.
• Made the VaultBlockEntity#serverData field public to be able to directly update the server data, without having to access the actual tile entity.

[Grabsky]

May not be the scope of this PR, but perhaps these could also be addressed here?

• VaultUnlockEvent #11687
• VaultStateChangeEvent #11679

Or would this rather be a separate PR?

[Warriorrrr]

May not be the scope of this PR, but perhaps these could also be addressed here?

* [VaultUnlockEvent #11687](https://github.com/PaperMC/Paper/discussions/11687)

* [VaultStateChangeEvent #11679](https://github.com/PaperMC/Paper/discussions/11679)

Or would this rather be a separate PR?

My current scope is just the vault block, I'll change the PR name

[Warriorrrr]

Would a Collection or SequencedCollection return type make more sense for this method, instead of guaranteeing a Set?

[FireInstall]

Well, the question boils down if ever in the future it could make sense listing a player twice, doesn't it?
My take would be, that it doesn't make sense to use a general Collection, since the vault basically just keeps track of whom to not reward any time soon again, not a complete history.

[lynxplay]

Actually pretty unsure on this statement.
A set would be useful for insertion schematics, but the returned thing is unmodifiable/immutable anyway.
Consumers cannot do anything about the contents in the first place but calling contains which, that works on a collection just as well as on a set.
I don't see much benefit from this being a set, tho I'll chat it over with others.