Update libv8 from 3.16.14.3 to 3.16.14.7

This selfish change fixes 'bundle install' on my (OS X) development
machine.
Improve MR code reloading when push code

Every time you pushed to master it updates merge requests that has master
as target branch. So if you have 50 open merge requests point to master
it will reload all of them every time you push a single commit to
master. The funny thing is that after reloading diff of most merge
requests looks the same.

After this patch we update diff only if we push commit to master that
includes in MR commits list.

For example we have next repository:

feature: A - B - C
master: A

We create merge requests #1 with code from feature to master.

MR #1: B - C

If we push to master commit D - MR will not be reloaded. So picture will
look next:

feature: A - B - C
master: A - D
MR #1: B - C

And if we push to master commit B - MR will be reloaded. So picture will
look next:

feature: A - B - C
master: A - B
MR #1: C

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Reload mr code on force push too

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Merge branch 'update-libv8' into 'master'

Update libv8

For some reason I could no longer install the previous version of libv8 on my development machine; this version bump fixes that.

I do not know if/how this change affects production environments.

See merge request !1287
Merge branch 'improve-mr-reloading' into 'master'

Improve MR reloading

## Theory

Every time you pushed to master it updates merge requests that has master
as target branch. So if you have 50 open merge requests point to master
it will reload all of them every time you push a single commit to
master. The funny thing is that after reloading diff of most merge
requests looks the same.

After this patch we update diff only if we push commit to master that
includes in MR commits list.

For example we have next repository:

    feature: A - B - C
    master: A

We create merge request with code from feature to master.

    MR: B - C

If we push to master commit D - MR will not be reloaded. So picture will
look next:

    feature: A - B - C
    master: A - D
    MR: B - C

And if we push to master commit B - MR will be reloaded. So picture will
look next:

    feature: A - B - C
    master: A - B
    MR: C

## Benchmark

For project with 45 open merge requests to master

Before

```
Benchmark post-receive | Cache and size:   0.060000   0.040000   0.100000 (  0.379720)
Benchmark post-receive | Push commits selection:   0.130000   0.020000   0.150000 (  0.149299)
Benchmark post-receive | Update merge requests:   9.180000   2.030000  11.210000 ( 11.971747)
Benchmark post-receive | Process commit messages:   0.140000   0.010000   0.150000 (  0.168810)
Benchmark post-receive | Push data:   0.020000   0.000000   0.020000 (  0.016363)
Benchmark post-receive | Push event and services:   0.030000   0.000000   0.030000 (  0.088062)
```

After

```
Benchmark post-receive | Cache and size:   0.070000   0.030000   0.100000 (  0.106676)
Benchmark post-receive | Push commits selection:   0.130000   0.020000   0.150000 (  0.143081)
Benchmark post-receive | Update merge requests:   0.660000   0.210000   0.870000 (  0.892663)
Benchmark post-receive | Process commit messages:   0.030000   0.000000   0.030000 (  0.029263)
Benchmark post-receive | Push data:   0.020000   0.000000   0.020000 (  0.018479)
Benchmark post-receive | Push event and services:   0.030000   0.000000   0.030000 (  0.038230)
```
- - -

## References

Discussion in gitlab/gitlabhq#1796

See merge request !1288