How should we handle palette arguments?

[Firigion]

The idea is to implement the WE-style arguments 10%stone,20%dirt,40%cobblestone_slab[type=bottom] for block placing functions, which is what I'm calling palette. This can be extended to also implement palette from clipboard, from selection and form the contents of a held shulker box. The parsing of the argument type has already been done by @BisUmTo in a separate file, though it only parses 'clipboard' and the compound block type argument. Should be easy enough to also add 'box' and 'selection'.

The idea then is to just override the block type argument with this custom one and all block setting functions will automatically support this behavior.

There's now two questions:
1. How do we properly implement the random selection of blocks without impacting the game performance heavily?

This is currently how the argument type data structure looks like:

NOTE: right now the suggester doesn't properly suggest block states and values, so this would not be able to safely replace the block type. I'm assuming this can be fixed/added.

2. Should we include the ability to store palettes (as implemented in #30)?

This makes it way easier to reliably use the same palette without having to type out the command every time and change between palettes. If we include it, this raises the question, how does the UI for this work? Do we need to duplicate all block setting commands to include a variant to support this? Or is there a more streamlined and clever way to do this? The idea is to have the ability to call stuff like /se set <block> and /se set form_palette <index>, and maybe also /se set form_shulker, if the user doesn't want to save a palette and rather wants to use it directly.

[Firigion]

Regarding 1.

We would need an efficient way to only pick block_id from the map if the list has only one item, but also randomly choose form the lists and sublists (for block tags) when the list is longer. Two suggested ways are (feel free to add better algos):

i. Add up all the weights and pick a random number up to that value, check if it's lower than the first weight. If so, first block is chosen, if not, check if it's lower than the cumulative sum of the first two values. If so, choose the second one, if not, check the cumsum of the first three, and so on.

ii. Create a list containing each block or tag as many times as the weight indicates, choose a random element from that list.

I'm not sure which would be more expensive: the overhead of creating the list plus accessing the list in a given location each time (I'm assuming accessing the list is O(1)?), which would be O(N) plus the overhead (maybe non negligible in this case?), or doing multiple checks each time, getting rid of the overhead, which would be O(N*M). I'm taking N to be total amount of blocks to set and M entries in the list, which is likely to be a small number.