Devise a plan for distribution, testing and update of core software

We need to come up with a plan for how to structure the distribution and updating of code in CodeCity.

Just looking at the server/database (ignoring connect and login servers and client software), there are several components:
1. The server proper, including the interpreter: the code that node.js executes directly; handles networking, checkpointing and running userland code.
2. The polyfills.
3. General-purpose infrastructure: user accounts, REPL, webserver, logging & auditing tools etc.—stuff that would likely be of interest to anyone using CC to serve content on the internet.
4. The CodeCity 'world' infrastructure: prototypes for rooms, avatars, etc.—stuff that is only relevant to MOO-like usage and/or with our comic client, but which will be needed by most/all .codecity.* instances.
5. User content: stuff created by us and our users for use in our instance.

Items 3 & 4 are what we would traditionally think of as "the core". (There are probably further subdivisions, but these are the principle ones.)

Some mutually-contradictory desires:

* Be free to hack on items 2–5 in-world.
* Be able to write and run tests for items 2–5 in-world (especially as a way of setting a good example).
* Have a single source of truth for tests of items 1–2 (ideally based on external ECMA compatibility test suite, though likely with additions and modifications).
* Be able to easily distribute updates to items 1–4 to other instances / installations.
* Be able to mange code for 1-4 in git or similar version control system.

Some possible strategies (not all of which are compatible with each other or all the desires):

* Developing code (esp. for items 2-3) as text files stored in git alongside the server sourcecode.
* Loading and/or updating code by feeding the server a text file at startup (possibly in addition to an existing checkpoint file).
* Keeping some version information in the database (maybe a single version number for each of items 2-4, or perhaps a version number on each prototype object).
* Having "corify" routines to export snapshot of core as checkpoint file or as .js text file.
* Building a git implementation in-core.
* Writing a preprocessor to convert an existing JS test suite to a form we can run.
* Having a "test" database core to run ECMA compatibility tests.

Some difficulties we will have to deal with:

* Corification is quite challenging; LambdaMOO's corification routines were not very robust.
* Though this might be assisted considerably by having routines that can do checkpointing to plain .js files.
* Other instances will have customisations they will want to keep (especially to item 4, which will likely see considerable customisation for different languages etc.)
* Code to do updates is necessarily going to be a little different than code that creates a new instance (or needs to be more complicated if it is to reliably do both).
* Certain kinds of updating (when touching stuff that has closures) may be difficult / impossible to do in-database.