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.
This is not very important, it's always a tradeoff. Having a class touching many so different contexts might lead us to what is called as "Divergent Change" code smell. This environment class is doing a lot of different things:

- Holding the configuration
- Parse/Compiling logic

I would suggest to go with a separation of duties and place the configurations on a proper class and use a message chain to get/set them.