Use mappings for data model options and attributes

[eemeli]

Closes #716

As discussed in the parent issue and its other follow-up #751, the order of options and attributes should not matter for their formatting or other processing. Reflecting this in the data model by making these use a mapping makes it clearer that e.g. {:foo one=13 two=42} and {:foo two=42 one=13} should be considered equivalent.

Note, though, that the order isn't completely lost here. The TS data model uses an ordered Map for these, and numerous JSON processors provide guarantees about retaining the order, even though the JSON spec does not require that. So making this change does not in practice make it harder for message syntax serialisers to retain the order that options or attributes may have had originally.

[aphillips]

Good start. I think this is the right direction.

[catamorphism]

As part of this change, I think it would be useful to change https://github.com/unicode-org/message-format-wg/blob/main/spec/errors.md to add a new category of errors. I'm not sure what it would be called, but it seems weird to call "duplicate option name" a data model error if messages that have this error are unrepresentable in the data model. When I read "data model error" I imagine a property that can be violated by a data model. I think it would be useful to define a category of errors that aren't syntax errors, but that have to be checked before constructing a data model.