Refactor template model

Some highlights:

* `RenderConfiguration`, `CompileConfiguration`, and `ParseConfiguration` have been combined into the `Environment`
* The various `Resource` implementations (`StringJtwigResource`, et al) have been refactored into a set of `Loader`s and `Resource`s. The `Environment` is now solely responsible for managing the resolution and loading of resource. Multiple loaders may be specified through the use of the `ChainLoader`. As a result, the resolution process should always return a path relative to an arbitrary resource root, in much the same way as we specify a resource as 'client/list.twig' and whatnot.
* Concurrent rendering demonstrated a hang when the output stream wasn't specified. This is resolved with an exception noting the problem. Helpful in unit tests
* Unit tests have been widely refactored for uniformity, in addition to the refactoring required due to all my other changes.
* Template caching is now supported. At minimum a per-execution cache is required due to the new resolution and loading process, but the cache can be cleared after execution. In my local tests, render time drops considerably on the second run. I've seen a drop in one of my projects from ~1200ms to ~25ms after a second run. TODO: Auto-clear the ExecutionCache after rendering has completed.
* With the existence of the `Template` and its implementations, we now have a place to store per-template information, present examples being `Macro` and `Block` information, for later usage. This also allows us to use the SetVariable tag during template extension.
There is no reason that subclasses shouldn't be able to access and/or manipulate object state. If there was a reason that object state should be immutable, then I would declare them private, but as it is conceivable that one might want to subclass the `Environment` for some reason, I'd rather retain the ability to easily handle the state of the subclass.