Attempt to find the keyboard by traversing the view hierarchy if it was not found
Fixed Podfile and Podfile.lock in example to set the path to "../" instead of "../TAPKeyboardPop.podspec"
Added UITextView example to showcase the need for a fallback "findKeyboard" method in TAPKeyboardPop
Updated fallback keyboard detection to @davelyon’s improved approach instead of traversing the view hierarchy
Merge pull request #9 from jpsim/master

Attempt to find the keyboard by reassigning first responder
Ensure that responder isn't set again if wasn't

Sometimes, dismissing the keyboard then starting and canceling an
interactive transition would cause the first responder to be set upon
coming back to the view, but the keyboard would be missing. This ensures
we don't assume any state of first responder restoration on a canceled
interactive transition.
Release: Version 0.1.2
Only intercept transitions that were initiated interactively

`[UIViewControllerTransitionCoordinator initiallyInteractive]` returns
true only if the transition is both animated and interactive.

https://developer.apple.com/library/ios/documentation/uikit/reference/UIViewControllerTransitionCoordinatorContext_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/UIViewControllerTransitionCoordinatorContext/initiallyInteractive

This fixes bugs caused by non-interactive transitions, some of which
aren't even panning, such as modal presentation transitions. Another
way to fix modal transitions whould be to check `presentationStyle`,
but from what I can tell we only need to handle interactive
transitions anyway.

Signed-off-by: Evan Owen <kainosnoema@gmail.com>