Split public mod into pyrogenesis and 0ad mod

[elexis]

As discussed since December 19, 2017 in ​https://wildfiregames.com/forum/index.php?/topic/23576-splitting-0ad-content-from-the-js-engine/ and discussed with Philip in irc on 2017-12-23:

Use cases and Implementation:

The public mod should be split into:

1. A pyrogenesis mod that contains most simulation components, shaders and rng files (since references to these are hardcoded in C++ and the pyrogenesis engine is intended/written to have these files present).
2. A 0ad game content mod, that can be replaced by other game content such as the formerly planned 500ad or millenium ad. This is currently impossible as all mods require to be built on top of 0ad, rather on top of pyrogenesis.
3. A gaia mod, so that the terrain textures, flora, fauna, geology don't have to be reinvented if the RTS using pyrogenesis takes place on earth at some time.
4. A pyrogenesis-gui mod, that allows one to reuse or replace the entire UI (without having to distribute the replaced GUI).

Possibly also:

5. A petra-ai mod, so that pyrogenesis games can be bundled with arbitrary AIs.

Verification: Running git diff master --summary master..HEAD | grep rename | cut -d "{" -f 2 | cut -d "}" -f 1 | sort | uniq -c | sort -n -r shows the numbers of files moved, the part of the path that changes (thus ruling out any typos and renames that change more than one parent directory name):

  13708 public => 0ad
   4587 public => gaia
    680 public => pyrogenesis-gui
    485 public => pyrogenesis
     28 public => petra-ai
    204 mod => pyrogenesis-gui
     36 mod => pyrogenesis
      1 mod => 0ad

Observations and gotchas:

• A lot of artwork and other duplication becomes visible when splitting #5361.
• Simulation component tests benefit, as they don't require the public mod anymore.
• Atlas currently hardcodes the launching of a "public" mod. This can be changed to requiring any GUI starting page (and otherwise the bare minimum).
• Translation resource names currently contain "public"
• The GUI engine hardcodes the presence of a mod selection GUI page.

This should be abstracted to a starting page decided by the launched mods, and show a human-readable error message if no starting page is present, possibly a fallback attempt to launch pyrogenesis-gui if present, so that the user can still use the GUI to configure the mods if unintentionally disabled pyrogenesis-gui.

Since it should be possible to bundle the pyrogenesis engine without our ugly theme, fonts, sprites/textures/icons and UI sounds, it would be bad to move these parts into the pyrogenesis system mod. There is no distinction between the mod selection GUI page and the other GUI pages other than fallback GUI support for incorrect mod configurations.

Instead, as far as I saw, it is the most reasonable decision to bundle all current GUI styles, sprites, icons and pages in a single mod, i.e to combine the "mod" mod's mod selection page and its UI dependencies with the "public" mod UI pages, as:

1. Mods that rely on the existing public mod GUI already require both mods.
2. Mods that don't rely on the public mod GUI come with custom fonts, sprites, textures, UI sounds and have implemented every GUI page except one manually, thus have no significant cost added to implement this starting page as well.

• A new pyrogenesis-examples mod would be useful to store the demo maps and contain examples how to implement a new simulation component, template, GUI page, sprite, style and so forth.

• Developer mistakes now become much more obvious when hardcoding 0ad terms into the pyrogenesis/simulation/, pyrogenesis/maps/random/rmgen/ or pyrogenesis-gui/gui/. For example the lobby JIDs use the resource 0ad, Regicide requires Heroes, civs and templates are hardcoded in few places in the the AI and rmgen library. The UI has several strings and textures that relate to 0ad, such as the version name, wildfire games links, game content information, etc.