Finish jsonizing terrain/furniture:

No more(*) enums. Terrain and furniture ids are defined by string, from "id" in their respective jsons.

The old t_rock, f_bathtub etc barewords are still available as *optional* global ints, which are automatically set to match the respective "t_rock", "f_bathtub" etc strings. Using the bareword makes sense for core terrain types that require modules, in all other cases string should suffice (and is required for stuff added via mods).

ter_set(x,y, t_shrub) and ter_set(x, y, "t_shrub"); have the same result.
ter(x,y) returns the int ter_id, as before. ter_get(x,y) will return the string.

Saves work as before; integers are recorded in maps.txt, however a jsonized key is provided. On load, this is used to create an int->int mapping, so a save will work across revisions or load order. If the game does not contain a terrain or furniture within the save, a warning is shown.

Technical bits about the variable changes:
Terrain:
+ string ter_t.id: Definitive identifier provided from "id" in .json
+ termap["string"]; returns a ter_t with id "string"

+ int ter_t.loadid: This is a load order counter, and similar to the old enum.
+ terlist[int]: This works exactly as before, however no assumptions are made regarding order:
+ t_rock, t_water, etc: These are populated after json load. New terrains should *not* require a new t_whatever global, unless that terrain will be involved in a ton of checks (lightmapping, etc).

Furniture: Exactly the same as above.

catatiles now uses terlist[n].id instead of terrain_names and furniture_names.



Note(*): The old enums were renamed, and all switch statements with f_ or t_ cases were made to use them. This is *temporary* until the switch statements in question are rewritten, however (concerns for messiness aside) there is no technical reason to rush; the switch statements use temporary oldfurn() oldter() functions that automagically ensure old_t_rock is always "t_rock".

ie; Safe to merge(tm)