Skipped previously unskipped flaky tests and did some minor corrections on TestExpectations.
Enable Context Menu properly

Make Nix build with Context Menu support
but without the cross platform implementation.
Next step will be to provide an API for the embedder
to customize its own context menu and return
the selected item.

Reviewed By: Luciano Wolf
Unreviewed gardening. Skipped failing tests.
Merge remote-tracking branch 'trunk/master'
Build fixes after merge.
Merge remote-tracking branch 'mainline/master'
Simplify MiniBrowser to use Options directly

Reviewed by: Luciano Wolf
             Jesus Sanchez-Palencia
Unreviewed gardening. Skipped the majority of failing tests, added test expectations.
Add Context Menu WK2 C API to Nix

Summary:
Make use of the patch from https://bugs.webkit.org/show_bug.cgi?id=109698
to add the needed C API to Nix. Also implements a shell based context menu. :)

Reviewed by: Luciano Wolf
Unskip contextmenu layout tests that are passing

Reviewed by: Luciano Wolf
Clean up USE_CROSS_PLATFORM_CONTEXT_MENU from Nix files

It does not fit our use-case.

Reviewed by: Luciano Wolf
Fix suspend/resume API test that was flacky.

This test was relying on sleeps to ensure that it would have time enough
between the title reads. That was a wrong assumption. As it uses a
ForceRepaint as client this test must be driven by forceRepaint() calls.

These calls in conjunction with requestAnimationFrame (on HTML side) ensure
proper UI updates and correct title reads. A forceRepaint() was added before
suspend to ensure UI update before scripts got suspended. This was enough
to correct the test.

Reviewed by: Rafael Brandão.
Gesture recognizer should be resetted when touch is handled by WebProcess

In the past, we could hit some unexpected states on gesture recognizer when the page
was dealing with a subset of {touchstart,touchmove,touchend}. At that time, we've decided to
shut down in gesture recognizer  in a page that would manage any of them, but this is tricky to
maintain and "didStartProgress" does not always track every real "page change" or any part
of it (via ajax for example). So once we get into the dead state of not recognizing any gesture,
we would never get a single tap and never do any navigation.

An easier solution is just to reset the state of the recognizer whenever the page handles
any touch event, since recognizer might be damaged by untracked events. Now, at the initial state,
we admit the possibility to get things like "move" or "end" without a preceding "start", but we're
just not moving forward in the state machine.

Reviewed by: Luciano Wolf
             Tullio Lucena
Checked skipped svg folders, unskipped, rebased tests.
Also fixed an other skip patch that commited partly.

Reviewed by Nandor Huszka.
Disable legacy vendor prefixes, following Adam Barth advice[1].

[1] https://lists.webkit.org/pipermail/webkit-dev/2013-February/024013.html

Reviewed by: Jesus Sanchez-Palencia
Fix Suspend/Resume API test

Adding sleeps again. When testing locally it performed as expected
without Util::sleep(). Although the buildbot still complains. I'm
adding the sleeps again to ensure it has time enough to collect the
samples. Locally it still performs as expected.

Reviewed by: Rafael Brandão.
Merge commit 'b9b7af1dab5ff8cc8bf10a72d31ce470d6967928' into merge
Unreviewed gardening
Merge remote-tracking branch 'origin/master' into merge
Long tap should trigger a context menu

Once we get the first touch start from initial state, we move to
state "single tap pressed" and start the long tap timer. If we get
any touch before the timer finishes, then we don't have long tap,
so the timer is stopped and the state machine moves forward like
before. Otherwise, if no touch happens before the timer ends, then
we have a long tap, and reset the state machine again.

In order to request a context menu, we use a synthetic mouse event
to simulate a right click on that point.

Reviewed by: Jesus Sanchez-Palencia
             Hugo Parente Lima