Terrains: Distinguish tiles by more than just their sides

Nobody has claimed this yet.

### Background
Sometimes, it is necessary to label tiles as having particular Terrains on their edges and/or corners so just that the Terrain tools can be aware of them. For example, a terrain set for placing grass and dirt may need to be aware that certain props, fences, etc are "grass" and some are "dirt" when painting near them. However, we don't want to ever place these props, fences, etc when painting "grass" or "dirt".

### Problem
The usual advice in this scenario is to set the unwanted tiles' probability to 0. However, the probability setting may also need to be non-0 for other purposes, such as for random mode on the stamp brush, or for random variants within another terrain set - in fact, a Terrain where some required tiles have probability 0 won't work at all. It is not reasonable to change the tile probabilities every time one wants to do a slightly different task. Scripts can be used to speed this up, but this should not be necessary.

### Proposed solutions
To solve the specific problem described above, some way to tell Tiled "this is what this tile connects to, but it's not really part of these terrains" would be enough, perhaps as an additional "ban" marker you can paint on the tileset for each terrain Set, or as per-Terrain Set probabilities on tiles (good luck with the UI on that xP).

However, I feel that fundamentally, this is really the same problem as that of "island" tiles, where Terrains currently have no way to distinguish between an island tile that has water on all sides, and a water tile that is water on all sides: both problems are about distinguishing between what a tile *is* from what a tile *connects* to. An island tile is not water in the same way that a fence surrounded by grass is not grass.
Allowing users to label the *centres* of tiles with a terrain to signify that's what a tile *is* would give users a way to communicate their intent to the Terrain tools, and Tiled would be able to preferentially choose those tiles that are relevant to the user's intent. To use the island example: if I start with a sea of water tiles and click with the Land terrain in the middle of a tile, then I probably want a 1x1 island tile if that's available. I can then keep painting more land by drawing over corners/edges and middles. If the desired "intent" is not available (e.g. if I click with a water Terrain in the middle of a bunch of land, but lack 1x1 lake tiles), then matching the sides should take priority - if I click the middle, that tile will remain solid land because that's the only available tile with all land sides, but if I click a corner, then Tiled would be able to place four water-land corner transitions as normal.
This same distinction would allow one to distinguish tiles that have labels just for "informational" purposes versus ones the Terrain tool should actually place.

Since this last change would require adding a 9th point of interest to the WangId of a tile, the current 64-bit storage would no longer work. Perhaps this change is best considered in combination with supporting more than 4 sides per tile, e.g. for hex tiles #2824. Edit: Or we could steal a bit from each existing point, reducing the max colour count from empty+255 to empty+127, which is probably still enough for any tileset out there, and with 7 bits per point, that would allow storing 9 points in 63 bits.
If this is implemented, older Terrain Sets that don't have middle labels would be treated as just having all empty centres, i.e. there's nothing to break any ties for tiles that have the same edge/corner labels, and would work as they always did.

Start by reviewing the Terrain tools, Terrain Sets, and WangId handling described in the issue. Define how centre labels should affect tile selection, how the WangId storage format should change, and how older Terrain Sets remain compatible; the proposed behavior and data representation need design decisions before implementation.

Written by the indexing model from the issue text.