WIP on #159, trying to drastically refactor the subprocess (in C#, which is debuggable and hence a HUGE plus in what we are trying to achieve...). Will also consider using the C API for CEF, since I think it actually will suit us better.
Taking a slightly different turn here; wrapping the C API (which I had as an idea to avoid having to do a bunch of needless wrappers) seemed too awkward because of the refcounting et al... We have to go with the C++ route after all, but we will still keep the subprocess in C# since it's clearly nicer.
CefBrowserWrapper is a bad name, since it will shortly be used by something entirely different. :) So let's rename that one to ManagedCefBrowserAdapter, which also more accurately describes its purpose.
More heavily-WIP-style work towards #159. I wonder if we'll ever gonna get that one solved actually...  Well, of course we are, but how well with it work? Anyway, time to go to bed now and so forth.
Moved the OutputDebugString P/Invoke signature to a separate “Kernel32” class.
Lots of work towards #159.
Bug fix related to #159. We cannot bind to an endpoint address already in use, so we must send in a request to terminate the endpoint if it’s already there…
Merge pull request #208 from cefsharp/CefSharp3-managed-subprocess

Merged in the CefSharp3-managed-subprocess branch
#159: Added DelegateCommand<T>, since we need it for the Run buttons that will let us run our Javascript code.
Whitespace fix.
#209. Can there be anything more fun than deleting old, no longer used code? I don’t think so. :)
#209. Let’s make it a bit more apparent that we are doing stuff asynchronously.
#209. Added a UI for these parts (simple JavaScript execution, optionally synchronous).
Added trick to make debugging the subprocess a tad simpler.
#209. You don’t need these droids. Move along.
#209. Added exception handling for the evaluate/execute JS stuff.
Let’s move the backing fields closer to the actual properties which exposes them.
#209. Fixed the JS execution UI to be a bit more reasonable, at least.
#209. Let’s try to avoid the “everything-is-glued-together” style of UI…
#209. Let’s add some nice HTML documentation about this also, shall we not?