Improve map hard-coded id handling, fixes for save game queued droid orders

[past-due]

Behavior changes:

• Use hard-coded map object ids only for matching up with labels.json info (mapping them to the new generated id on labels.json load).
  • (Does not impact savegames, which obviously must preserve the ids on loading.)

Backwards-compatibility impact:

• Only if scripts hard-code an object id (that they are expecting will match the one hard-coded in the map droids/structures/features.json file) should this be a problem. (And they shouldn't be doing this!)
  • Solution (if impacted):
    • Do not hard-code object ids in scripts.
    • In one of the script init events, get the actual object ids by enumerating (via enumDroid/enumStruct/enumFeature, or via area labels w/ enumArea, etc), or by using object / group labels in labels.json (which will properly map to the hard-coded map object ids).
    • Any object ids properly obtained via API functions in the script can then be stored / saved (and persisted through savegames).

Also:
Fixes: #2227
Fixes: #1160