Build a special mode for editing automapping rule maps

I'll start with the summary: when editing an automapping ruleset, replace the Layers panel with a slightly different panel that allows you to create the following types of layers:

* Comments - a "group" that can contain anything
* Logical Operators - a "group" that can only contain inputs and comments
* Groups - a "group" that can only contain outputs, objects, and comments
* Inputs - a "tile layer" used for input
* Outputs - a "tile layer" used for output
* Objects - an "object layer" used for output
* I may have missed something, so don't assume the above is absolutely comprehensive.

-----

Rule maps are tile maps… but with a number of special conventions that are, currently, not even remotely enforced, and are also somewhat confusing.

I think it would be beneficial to have an entirely separate document type for editing rule maps.

Now, they are still tile maps, so "entirely separate" isn't quite right. It would be a specialization of the map editor, for the most part. At present, I can think of only one differences I'd like to see from the regular map editor:

_**The Layers Panel**_ should be almost completely different.

In a regular map, you can add image layers, groups, object layers, and tile layers. That's fine.

But in an automapping rule map, that's not _quite_ the case. I haven't tested, but I _think_ image layers are basically unsupported (presumably, just ignored by the automapping system?). So maybe it makes sense to forbid them entirely. Furthermore, while groups and object layers remain mostly the same, tile layers are, in fact, two almost entirely different things: input layers, and output layers.

Technically speaking, the input and output layers are still tile layers in most ways. However, they share some extra properties that regular tile layers don't have:

1. Logical operators. Input layers can be ANDed or ORed together to produce the resultant rule. Currently, this is done in something of a confusing way: if they have the same index, they are ORed. Otherwise, they are ANDed. There is also support for logical NOT. (It's _possible_ I got confused and it's the other way around. This goes to show that it is quite confusing how it currently stands.) In other words, if you have layers `input1`, `input1`, `input2`, `input3`, that's like the logical expression `(input1 | input1) & input2 & input3`, with the added confusion that you can't give the two `input1` layers different names (which may or may not be fine, depending on the complexity of your rules). I believe it would be better (and significantly easier to understand) if this logical structure were encoded into the tree view, rather than the layer name. Doing so could even make the system more powerful – right now you have no way to reverse the precedence to produce an expression like `(input1 & input2) | input5`, but if it's encoded into a tree, then the tree itself establishes the order of precedence.

2. Randomization groupings. Output layers can be grouped into sets, such that the system will randomly choose one of the sets and use all the layers in that set.

3. Target layer. Each rule targets one layer in the source map. This is currently encoded into the layer name. It could instead be a special property of the layer, which can be edited in the properties panel like any other property, but can also be edited in-place in the automapping layers view.

Internally, I don't think much, if anything, needs to change about the format of rule maps. At most, I'd suggest making group layers significant, and using them internally to create the tree levels for points 1 and 2. You could still add group layers directly, and those would be treated as "comments" and do nothing; but group layers that are marked as "logic" or "randomization" layers would determine how the rules are worked out. You _could_ internally convert logic trees back into special rule names that are parsed like they currently are, but that seems like it would be more trouble than it's worth. Though, I'm not really the one to judge this.

Start by tracing the existing automapping rule-map handling and the Layers panel in the map editor. Clarify how specialized input, output, object, comment, logical-operator, and grouping layers should be represented and edited. Done means a dedicated rule-map editing mode enforces the supported layer relationships without changing regular map editing.

Written by the indexing model from the issue text.