Swappable Configuration implementations

[ethan.jucovy@…]

On some systems, it may be useful to initialize the Trac Environment with a non-standard Configuration object. Use cases include:

• Deploying Trac on Heroku with configuration from environment variables instead of trac.ini. Heroku provides ​an ephemeral filesystem; directly writing changes to files (vs. updating files locally in a git repository and pushing those changes to your Heroku instance) is risky, because those changes may disappear at any time (e.g. when redeploying code or when Heroku decides to reboot a system) and are not shared across application instances if you scale up your deployment. Meanwhile, Heroku *does* provide ​a persistent environment variable layer that can store up to 16kb of data. For a Heroku Trac deployment, a Configuration class that reads and writes its values via a JSON-structured environment variable would be more appropriate than a file-based configuration.

• Preventing through-the-web changes to the configuration altogether to ensure that formatting and comments in a hand-edited trac.ini are not lost, until #7378 is closed.

• Ensuring that trac.ini remains version-controlled by extending Configuration.save()to write out a diff from the previous file, or to commit changes directly to a repository in a subprocess.

See ​[Trac-dev] Setting database string from environmental variable?" for motivation.