v8 has ever invented TypedArray, which maps JS array to fixed-length
element memory, originally for canvas pixel support. We utilize it
for bytea conversion and int/float array. In the array case, we had
to annotate the type by domain as it's an external array type to JS,
otherwise, we would loose the current flexibility around array conversion.
Those annotation type names may be changed in the future. Also, it
might be reasonable to introduce TypedArray such like in d8, in order
for users to make their own fixed-length element array, but it will be
a different story.

The feature is enabled only if make is given ENABLE_DEBUGGER_SUPPORT=1,
because we are not sure how much of v8 installations are with debug
enabled. Maybe it is safe to flip the flag to DISABLE_DEBUGGER_SUPPORT.
On the other hand, with static build, we are sure we can support it.

Now the json type is built-in since 9.2, it is reasonable to convert
the text representation to/from object. V8 doesn't expose JsonParser
interface to C++ client, so we ended up extracting JSON.parse/stringify
from the global context. There shouldn't be any performance gain
over the user script calling the functions, but it is only for convenience.
This breaks the existing script that calls JSON.parse/stringify.

Type 'make static' and it will download v8 source, builds it, and
do static link. It is still by default, as I think the dependency
download/build takes too long for people who expect a lightweight
installation, especially around PGXN. Will see if people want it
as default.

In some circumstances, it is convenient to link v8 statically while we still
build plv8 with dynamic linking by default. v8 supports both of dynamic and
static links, and also two modes of snapshot on and snapshot off in the static
library. It might be possible to find the mode by looking at the v8 directory,
but it is wise to let users explicitly choose it to avoid to shoot in the foot.
Also rethink V8DIR, which was not working well. Previous coding was not so
nice as the default value was quite unportable. Now we have two different
variables, V8_SRCDIR pointing to the v8 source directory, and V8_OUTDIR
pointing to the v8 build output directory. By default without specifying
them, the system will find the appropriate ones. We might want to introduce
our own configure script, but for now we stay in Makefile which is still
simpler than other solutions.

Ideally we want to have only one place for the version string, but parsing
META.json is a bit challenging; at one time we had v8/d8 parsing META.json
to pass this value to source file, but it turned out those utilities may not
be available everywhere. Since this integrity matters only developers,
we just check it if they are available. We may come up with a better
solution to have it in one place in the future.

LiveScript is yet another dialect of JavaScript, in a way we support
CoffeeScript. Although we put this as additional change on top of the
existing CoffeeScript support, we will need to refactor the code so
that more dialects can be easily supported.

Field names returned by SRFs much exactly match the expected
values, both in number and content. This is consistent with
the requirements of other PLs.
A couple of additional regression tests are added to monitor this.

We check that the right number of attributes are returned.
Still to do is checking that the names match one to one.
(The infrastructure is there, I just need to brush the cobwebs
off my C++ to write the actual name comparison test, and it's
too late at night for me to do that now.)

The mechanism is based on the variable parameter hook available since 9.0.
For 8.4, we still have to specify the parameter types. plan.execute,
plan.cursor is also updated to make use of this.
Change ValueGetDatum and InferredDatumType to lower_case functions, as
they look safe and natural to use outside of C++ try block. plv8_param.cc
is also a bit modified to reduce code complexity in plv8_func.cc. In 8.4,
plv8_param_state is never used, but leaving it in the source makes more
readable than hiding the definition completely.