use vm.Script to avoid reparse

[HerringtonDarkholme]

DISCLAIMER: I don't have enough knowledge in nodejs nor V8. I read most cpp/internal js is by guessing and cramming on cppreference.com :/ I welcome any correction!

This pr tries to alleviate the problem in #4872. When users include third party library into server bundle, the parsing overhead can be smaller.

If user provided global variable is compared with another global variable in library code, they will never be equal because they are executed in different context.

To fix this generally, we have to run library code and user code in the same context. This means we need to parse a lot of code in one request.

We can skip parsing by creating a Script object, and runInNewContext is effectively a shortcut. Thus it is safe to reuse the Script object.

Reusing Script should save several C++ call and reduce garbage collection pressure since the underlying C++ object has a Persistent which will not be collected until out of memory (it is cargo cult to me, though).

However, I cannot see a performance improvement in a simple benchmark, regardless of whether bundling library code into server entry. (I use vue-hackernews as example, tested under ab -n 1000 -c 100).
It seems v8 will cache compiled code. So parsing overhead is relatively ignorable in real world.

But reusing object is still a good practice, so I submitted this pull request for symbolic value.

[yyx990803]

Looks good to me! Can we add a test case for #4872?

[HerringtonDarkholme]

Sadly #4872 is not fixed in this pull request 😞 . It only reduce reparsing overhead so more library code can be bundled at the same cost.

If we bundle Vue library into the server bundle, #4872 can be fixed. It has been verified by existing tests.
If Vue library is required from external, #4872 will still have problem due to different execution context.

We can reduce the reparsing overhead as is done here, so bundling Vue library is less expensive. We still need users to configure their project to bundle library code together with application code if they need to use APIs which compare global variables.

[yyx990803]

Ok, I guess we can adjust prop type check strategy to not rely on globals instead.