Break up Modifier::Attributes

[kpreid]

Commit ec4813f moved the storage of BlockAttributes from the primitive to a modifier Modifier::Attributes. This allows more flexibility, such as applying arbitrary attributes to a non-primitive block definition, but there is still a deficiency: either the entire set of BlockAttributes is overridden, or none. This means it is not possible to, for example, give a block a name without also overwriting its actions, animation hint, etc.

I see two paths forward. One is to allow each field of BlockAttributes to be explicitly absent, and not override the prior value; the other is to break up Modifier::Attributes into many modifiers.

The latter seems more elegant (especially as it fits into a path of completely eliminating BlockAttributes as a public part of the API / schema, so there is no longer a question of what is inside the attributes and what is outside), but it adds more degrees of freedom to accidentally generate redundant stacks of modifiers, or just list them in an arbitrary inconsistent order.

[kpreid]

As of be82f4d, BlockAttributes has a lot of its structure generated via macros. I was hoping that this would enable macro-generated Modifier variants to set attributes. However, doing this in a flat fashion (variants of Modifier, not variants of a nested enum) requires nested macros that make rust-analyzer’s macro support unhappy. Also, I might want attribute-setting modifiers to be smarter than macro boilerplate (e.g. setting groups of related attributes, like “name” and “description” perhaps). I’m not sure whether I want to pursue that option or not.