Usage of `old-style callbacks' causes compilation failures against v8 3.27

[ignisf]

Relevant changelog entry: https://github.com/v8/v8/blob/3e283f444dfd2ffd4550f7c726888f427ec0a0ab/ChangeLog#L2033

[ignisf]

@cowboyd, what are your thoughts on this?

Pros of creating a branch that uses v8 3.27

1. Better compiler support: both clang and GCC up to 4.9 are supported without patching build scripts
2. Better ARM (cross)compilation support

Cons of creating a branch that uses v8 3.27

1. Need to alter therubyracer to use the new callbacks API (which may or may not cause breakage of dependencies) and account for few other changes in v8's API
2. Usage of system v8 becomes useless due to Virtually NO distribution providing such a recent version in its package system (Ubuntu and Fedora provide 3.14, Arch - 3.25.28)

Pros of creating a branch that uses v8 3.14

1. Will permit wider usage with system v8 (which will make usage on ARM easier for several popular distros)

Cons of creating a branch that uses v8 3.14

1. Bad compiler support (will need patches as with 3.11 and 3.16)
2. Bad ARM compilation support on distros that do not include v8 in their package systems

The main issue here is the instability of v8's API. TBH I'm not sure how this should be handled best

[ignisf]

There still are a bunch of distros shipping v8 3.14 (Ubuntu and Fedora), RHEL6 seems to be providing both 3.14 and 3.25, Arch is now at 3.26.31.

[cowboyd]

I think it's clear at this point that we're going to need to move forward with whatever version of libv8 helps us provide the best development experience with TRR.

--with-system-v8 is for those who wish to be responsible for compiling their own library from source, not those who wish to use whatever version of v8 happens to ship with their distro.

It's unreasonable for us to lock ourselves into a v8 API version when V8 is evolving so quickly.