Expanded options for referencing automapping rules

Nobody has claimed this yet.

I'd like to see more options for referencing automapping rules.

Currently, you have two options (and the second overrides the first – you can't have both):

1. A rules.txt placed in the same directory as the map.
2. A rules.txt referenced from the project properties dialog (only if you're using a project).

The rules.txt is somewhat complicated, and can be used to link together a web of rules.txt files if you really want. It has no support for wildcards, however. You can't specify "use all .txt files in that directory" or "use all .tmx files in this directory", for example.

It also has some filtering support to specify that certain rules only apply to certain maps. Here it _does_ support wildcards on the map names.

This is all pretty powerful, and I'm sure it serves many people's use-cases quite well, but it's also very fragile in a way. The rules.txt is a separate file, so if you send someone your map (for example, to get them to improve it), the rules.txt doesn't automatically go with it.

So I'm not going to propose removing or altering the existing framework; but I think it would be beneficial to have additional options for simpler scenarios. My suggestion is: add an "Automapping" list property to maps and tilesets. Each element of this list is a file – either a rules.txt, or an automapping rule map. There's no need to support filters in this scenario – if you really need them, you can reference a rules.txt file, but in fact, the place they're found is implicitly a filter already:

* Rule maps referenced from a map are _only_ used on that specific map. They're used in addition to any rule maps referenced by a project-wide rules.txt. In the case of conflict, ideally, the one specified in the map would take priority.
* Rule maps referenced from a tileset are _only_ used on maps that use that tileset. Other than that, they work as above. Here, there could be reasons to want additional filters though.

In addition, I think it would be good if the project-wide rules.txt could be edited in-place in the project settings – it could be something like a two-level tree view, with map reference nodes nested underneath filter nodes. Or, potentially, create a little mini-editor that can edit _any_ rules.txt.

Start by reviewing the existing rules.txt behavior and the project properties dialog, then trace how maps and tilesets currently reference automapping rules. Define the scope and precedence for map and tileset references before considering the proposed in-place project-wide editor; done means the feature design and its interactions with existing rules.txt files are settled.

Written by the indexing model from the issue text.