Remove auto-registered JS engines from React.Core

[dustinsoftware]

This started as an effort to remove VroomJs from the core library, and evolved into removing the default engine registration logic, so the core library can remain simple. The MSBuild project ends up registering the MSIE engine directly, which works fine. I updated a lot of the documentation to make getting started more clear as well.

Previous efforts are in #501, #459 , and #456

Once this is merged we can work on #566 :)

[DanBuild]

Website preview is ready!
Built with commit 0a73071
https://deploy-preview-582--reactnet.netlify.com/

[dustinsoftware]

Ugh.. cassette does not seem to work with .NET 4.5. Going to roll back those changes (should be minor)

[dustinsoftware]

Tested all the samples, they pass. This should be ready for review.

[dustinsoftware]

@Daniel15 can you give this a quick look? I've tested it but it's technically a breaking change (suitable for a 4.x release) since JS engines are no longer registered automatically.

cc @Taritsyn

[Taritsyn]

I'll try to reply in 36 hours.

[Daniel15]

This looks great to me! We can include this as part of the 4.x release, since we already have another breaking change (switching to newer JsEngineSwitcher beta version) :)

I do still wonder if we should remove the usage of JsEngineSwitcher.Current and instead use the IoC container to manage its life cycle. I guess that'd make registering JS engines a bit more difficult though. Probably not worth it?

[Daniel15]

We should upgrade this guide one day.

[Daniel15]

I wonder if a singleton instance of JsEngineSwitcher should be registered in the IoC container rather than using the static Current property.

[Taritsyn]

My suggestions are as follows:

1. Add a EngineName property to the IReactSiteConfiguration interface. The value of this property when choosing a engine must take precedence over the JsEngineSwitcher.Current.DefaultEngineName. This will avoid conflicts with other software products that use the JavaScript Engine Switcher.
2. It is possible that we should abandon the automatic selection of a working engine, because it introduces an element of randomness. The user still does not know which engine is currently in use.
3. If we ignore the second item, then before catching the exception, we should add the following code:

catch (JsEngineLoadException ex)
{
	Trace.WriteLine(string.Format("Error initialising {0}: {1}", engineFactory, ex));
	exceptionMessages.Add(ex.Message);
}

This code intercepts almost all common errors that occur when creating engines. In the Message property describes the reasons and ways to prevent such errors (see example).

[Taritsyn]

I do still wonder if we should remove the usage of JsEngineSwitcher.Current and instead use the IoC container to manage its life cycle. I guess that'd make registering JS engines a bit more difficult though. Probably not worth it?

This can introduce additional confusion.

[dustinsoftware]

Thanks for the feedback. I pushed an update to exception logging. Changing the way the default JS engine is selected seemed out of scope for this PR and I'm not quite sure yet if a web project would need default JS engine separately from the built-in handling in JsEngineSwitcher. As long as jsEngineSwitcher.DefaultEngineName is set, this library won't try to use another engine even if it has been registered.

So with that in mind, I'll merge after the build passes.