Better ter/furn copy-from support

[Procyonae]

Summary

Infrastructure "Better ter/furn copy from support, remove legacy alias code"

Purpose of change

copy-from good
Fixes #54702

Describe the solution

Requires #73268 to save me touching No Hope mapgen for no reason
Requires #73415 because I decided it was better to make it a seperate PR

More copy-from support:
"symbol" supports copy-from
TRANSPARENT flag inherits correctly
"flags" support extend/delete
"connect_groups", "connects_to" and "rotates_to" support copy-from

Removes remaining redundant aliases and alias code
Removes LINE_OXOX and LINE_XOXO handling replacing it with better generic unicode character handling. Currently changes symbols to what they were already using but when I add abstracts I'll probably make most walls # instead.
Removes legacy connects_to/rotates_to flag support.

Will attempt to ensure you can overwrite "bash"'s, "deconstruct"'s and "pry"'s "ter_set"/"result" without redefining the other values for stuff like doors where that's the main difference while allowing ie "bash": { } to correctly default all the fields inherited.
May add tests to check stuff like the above works.
Will likely update inheritance docs Nvm I forgot how atrocious our existing inheritance docs were for a moment

Was originally going to add abstract terrains/furniture to cut alot of json bloat but I'll now do that in future PRs

May remove legacy connects_to/rotates_to flag support if applying the necessary JSON changes in this PR isn't too much otherwise I'll leave it till after the follow-up PRs adding copy-from to alot of existing ter/furn
Will add abstract versions of basic terrain (probably just walls/windows/doors/floors/roofs for now)
Moves painted walls to their own file bc they were taking up half the file
Corrects several discrepancies between similar terrains

Describe alternatives you've considered

Testing

Additional context

I'd still like to make paint metadata instead of needing to have individual terrains/furniture but the save/load side of things isn't easy

NTS: Check using copy-from with an id of the wrong type (ter with furn or vice versa) throws an error. (While this could theoretically be supported I don't think it would be a good idea)

[PatrikLundell]

What do you mean by paint meta data? My interest stems from the issue of "terrain" completely overwriting information about the actual terrain, and thus making it impossible to restore the actual terrain when the "terrain" is removed (you have to hard code some best guess).
By the way, if you find some way to associate paint info to terrain, I assume the logic would also apply to carpets?

[Procyonae]

Basically I have a local branch that makes it so piant can be applied to any terrain with a PAINTABLE flag (and consequently removed by a chipper still) without changing the id of the terrain itself, just the visual stuff it displays. For mapgen I think I'm looking at doing it as a "colour": { "!": [ "blue" ] } type thing but autogenerated ids might make sense too (so t_not_painted_blue). I just haven't looked into how to add a new field to track it in savefiles yet and am mildly scared of breaking everyone's saves.
I also needed
It's been a minute since I looked at it but I imagine making it handle furniture too wouldn't be that bad it'd just need to prompt you in the case of both a PAINTABLE terrain and furniture on one tile.
Idk how carpets should be handled tho.

[I-am-Erk]

Can we also inherit colour? I see no reason to have to repeat it every time.

[Procyonae]

Can we also inherit colour? I see no reason to have to repeat it every time.

Yes?

[Procyonae]

Ok going through all our ter/furn in this PR is enormous scope creep I think I'll dial this back to just C++ and removing redundant JSON stuff and do abstract/copy-from stuff in seperate follow-up PRs