update mvc reference.
Update documentation link.
remove mvc version
Merge pull request #194 from matthid/latest_mvc_reference

Update the System.Web.Mvc reference.
fixes issue #163.
Merge pull request #195 from matthid/issue_163

fixes issue #163.
add unit test for 93 and 193 to make it clear what works and what doesn't. Fixes issues #93 #193.
./build Test_40
and
./build Test_45
can now be used to execute only the unit tests for net40 or net45.
Merge pull request #196 from matthid/project_settings

./build Test_40
Merge pull request #197 from matthid/issue_93_and_193

add unit test for 93 and 193 to make it clear what works and what doesn'...
Merge branch 'master' into develop

Conflicts:
	readme.md
Initial support for improved template debugging: #132, #87, #53.
For further improvements we need more information about where the template is comming from.
To get a "unified" debugging experience I will clean up caching and the general API first.
- Added an ICachingProvider interface to support user defined caching strategies: #47
- Redesigned the API in this process.
- Added Legacy classes to support the old API by using the new API (marked as obsolete).
- Within the redesign support for streaming the output of templates was implemented: #27, #169
- With the new API one can exactly control where the templates come from (ITemplateResolver) and how they should be cached (ICachingProvider).
- The old API works for the complete test framework.
ICachedTemplateService -> IRazorEngineService
ITemplateServiceCore -> IRazorEngineCore (and now internal)
Razor class is now obsolete and replaced with RazorService.
Depending on the information we have about a template we improve the debugging experience:
- When the TemplateSource has a not null file path we tell Razor to generate Line pragmas (which leads to better stacktraces on exceptions)
- In the other case when we are in Debug mode we leave the temp files so we can debug into the templates.
- In the future we want to give the Caching layer the possibility to save the generated assemblies, this means we need to have a byte[] member in ICompiledTemplate for the assembly. (Currently this is only possible in Debug mode by copying the generated assembly). We will provide this in the CompilationData class.
- Improved the CompilationException by providing more details and explaining common pitfalls.
Implement IsolatedRazorEngineService. This allows to run the templates in an isolated appdomain. Fixes #144, #96, #32
Fix the .net40 tests:
Wow. Razor2 has an SecurityTransparent assembly attribute, which later versions do not have. This is/was the root for a lot of confusion. This also means that now our .net40 lib is not binary compatible anymore with Razor3 (and the other way around).

See http://msdn.microsoft.com/en-us/library/dd233102.aspx for details. We now need to ensure that RazorEngine and (especially) Razor are loaded with full trust.
Improve classname generation: This should fix #135, #38.
Test the sandbox on IsolatedTemplateService (obsolete) as well.
modelType == null -> typeof(DynamicObject) instead of typeof(object). This will only change the "new" IRazorEngineService API. I think using "null" for "dynamic" is kind of nice (as typeof(dynamic) will not work).