Issue #3593 - Make isolate a fully internal member of the engine

Issue #3593 - Make isolate a fully internal member of the engine

Remove the isolate argument from the `JsEngine` factory method. This is an API
change. This argument was, however, only introduced to deal with #3593, and it
should not affect ordinary clients.

Create the isolate in the engine factory method instead of using an external
isolate or one from an argument default.

Remove class `ScopedV8Isolate`, which is no longer necessary. Its behavior has
been moved into the constructors and the factory. Added an engine destructor,
needed to call `Dispose()` on the isolate, which call was previously performed
by the removed class.

Clean up unit tests in the wake of not sharing an isolate. Added test points
to ensure that every use of the engine only has a single remaining (strong)
reference at the time it's destroyed (and fixed defective versions of this
test). This entails waiting for asynchronous tasks--I/O tasks must finish,
timers are interrupted. Replaced explicit calls to `new` with calls to
`make_shared`. In all cases this shortened the code; in a few cases it
eliminated some memory leaks.

[Eric, 2017-01-12 15:03:15]

Together will all the prior work on this issue and the blocking issues, this
change will be sufficient to close #3593.

The unit tests all pass, with one caveat. The tests that involve update have
race conditions that this change has exposed. The tests run very reliably
standalone, but don't always run correctly under the debugger, and with varying
kinds of failure. At least one of these tests is written with an obvious race
condition; it ought to be fixed. Regardless, all the issues like this are a
separate from getting the isolates under control.

https://codereview.adblockplus.org/29371607/diff/29371612/src/JsEngine.cpp
File src/JsEngine.cpp (left):

https://codereview.adblockplus.org/29371607/diff/29371612/src/JsEngine.cpp#ol...
src/JsEngine.cpp:142: *   and there will be no need to lock the isolate.
Apparently this comment is wrong with respect to the version of v8 that we're
using. Maybe it's true for a more recent version. It does seem from the
documentation that it's not necessary.

In the interim, I've removed the comment. It's not like it's a burden to keep it
in.

[Eric, 2017-01-16 15:59:57]

Patch set two was the result of a better audit of the unit test suites. We not
check the use count of each and every JsEngine instance. A few unit tests were
leaking them. All memory allocation was changed to use `make_shared`; this fixed
some dangling allocations.

Memory usage for the unit tests is down to 21 MB total. `DefaultWebRequestTest`
is single-handedly responsible for 5 MB of that; it seems to be leaking
something that's neither an engine or isolate. Without that test, everything
that runs under the debugger (a few with inherent races do not) only takes 16
MB, almost all of which is v8 overhead.

[Eric, 2017-01-17 16:35:42]

I investigated `DefaultWebRequestTest` to see if it's actually leaking. It
doesn't seem to be. Instead, much of the memory consumption looks to be an
inefficiency in memory usage. I've filed issue #4812 for it.

https://issues.adblockplus.org/ticket/4812

So patch set 2 seems to stand as fixing all the major memory leaks that we have
in the unit tests, or at least, all that can be addressed at this point.