Mac: History swiping can be cancelled with vertical motion.

Users accidentally initiate history swiping (which requires horizontal motion)
when they intend to scroll content (which requires vertical motion). Once the
browser enters history swiping mode, subsequent vertical motions are discarded.
This change causes the browser to continue to observe vertical motions, and if
the user's horizontal swipe gains sufficient vertical motion, breaks out of
history swipe mode and into content swipe mode.

This CL enables touch events for the RWHVMac. I stopped using the API
trackSwipeEventWithOptions, since the block callback discards vertical motion,
and the method prevents the window from receiving touches.  Instead, I record
all touches received by the window, and manually track the user's horizontal
and/or vertical motion.

Another independent change is that 2-finger swipe zone required to initiate
horizontal swipe mode was reduced. (Diagonal 45 degree swipes now initiate
content scrolling, rather than history swiping).

BUG=138175
TEST=Populate the browser's navigation history by visiting many different urls.
Use a 2-finger horizontal swipe on the track pad to begin a back/forward
navigation. Without lifting your fingers, swipe vertically. The history swipe
should be cancelled, and the content on the page should be scrolled. This
change should not have any effect on existing vertical content scrolling.
Interesting edge cases: Users use both short horizontal 2-finger flicks, and
long horizontal 2-finger swipes to navigate forwards/backwards. This behavior
should not be affected. When the content does not occupy the full horizontal
space (try reducing the browser window horizontal size by dragging the right
side close to the left side), horizontal swipes should swipe the content
horizontally, rather than triggering the history-swipe mode.

Review URL: https://codereview.chromium.org/87573003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239976 0039d316-1c4b-4281-b951-d872f2087c98
Make launching a terminated app from the launcher not crash.

http://crrev.com/235885 changed the semantics of GetExtensionById() to include
terminated apps. This changes it back to its old semantics (as per its comment)
and updates the call site that needed to include terminated apps.

BUG=316585,325023
TEST=Launch a Chrome App from the launcher, go Wrench Menu -> Tools -> Task Manager and kill the app, which should cause it to crash, launch the app again from the launcher. The app should launch.

Review URL: https://codereview.chromium.org/105883008

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239977 0039d316-1c4b-4281-b951-d872f2087c98
Add some code to make views_examples_exe more interesting.

At least now it will stay alive, until you get tired and hit Ctrl+C :)

BUG=119759,139313,141187
TEST=views_examples_exe runs and does not crash.
R=ben@chromium.org

Review URL: https://codereview.chromium.org/110893002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239978 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 239977
SVN changes up to revision 239978