Future of iAPI and eAPI

[pixelcmtd]

iAPI and eAPI have been in fairly inactive development for more than 3 years and still haven't really gotten anywhere. This is one of the worst failures you can imagine, and it has to be fixed. They either have to be officially discontinued, or finished soon. Here are my plans for them:

eAPI needs a really big rework. Two options:

1. We could use a better file structure with less files, like already suggested in we really need to stop writing so many files #15.
2. We could support a protocol like REST, gRPC, GraphQL, ... instead.

iAPI got some improvements in 316889e already, and it should get some more. But the real thing it needs is dogfooding. First of all, we can use its previous versions for patching #17. But the more important part is rebuilding the CXClient core to use the iAPI.

[pixelcmtd]

I have actually now come up with the perfect solution for the eAPI: It is replaced by my RCON ideas.

To explain that slightly: I have wanted to implement an RCON server in CXClient for a little while, just as a remote way of running CXClient commands (#foo). Now I have realized that this can actually replace the eAPI by just providing a few more machine-readable commands. (e.g. a command to list all enabled mods or get a JSON with the settings of all mods)