Multiple modmaps in a custom layout

[Spike-from-NH]

During the development of pull request #666, @Julow stated that any second modmap in a custom layout erases the previous modmap. This is not what the author wants. Julow's proposed solution is ➊ to document the rule that there can be at most one modmap (now done); and ➋ to issue an error on encountering an additional modmap (for which this issue is a placeholder).

The author might want multiple modmaps: He might believe it makes the layout more readable if each <row>...</row> is immediately followed by mods that apply to keys in that row. Unexpected could batch all modmap data before processing any of them, or set a flag that it has created a data structure of mods, so as to avoid erasing it on additional modmaps.

In fact, the author might want each key to be followed by mods that apply to that key, also for readability. This argues for also dropping the documented restriction that modmap must be inside keyboard but outside any row.

[Julow]

Having multiple modmap make little sense as a single <modmap> node can hold any number of mappings. Having modmaps inside rows make no sense internally. Let's enforce only one modmap is present.

[Spike-from-NH]

It's your call, and a minor issue in any case, but the "sense," again, is readability.

Having modmaps inside rows make no sense internally.

Of course, because the modmap is a separate structure. But it does make sense to the reader of the layout to group together all specs that apply to a given key. Why force the author to write according to the internals?

[Julow]

I'm not convinced having the modmaps between the keys would improve the visibility. That makes the rows harder to read as not every elements are keys and that makes it harder to see all the mappings at once.
The separate modmap is what makes the most sense at every levels.

[Julow]

I added some validation in 45fc185
This not complete and it's still possible to write nonsensical layouts but at least redefining the modmap is.

[Spike-from-NH]

This doesn't seem to have doc impact as, for now, it just enforces the rule we give.