New OnceUX UiAutomator Base class, New Test Class

New Base Class OnceUxUiAutomatorBaseTestCase.java, New Test Class LearnMoreCheck.java

##Rationale
This branch exists mainly to begin the process of merging the uiTests into master one at a time. The most stable test, **LearnMoreCheck.java**, was chosen to be the first implemented. The following is a rehashing of what has been been done in the **onceux-uiautomator-tests** branch.

With work on multiple tests underway, I wanted to provide a way to get the universal setUp and tearDown methods to each class without having to literally copy and paste them across each class file. This is where **OnceUxUiAutomatorBaseTestCase.java** comes into play. All further tests will now extend from it, calling down the super.setUp and super.tearDown methods. OnceUxUiAutomatorBaseTestCase.java also provides a playVideo method that most test methods will need to begin their testing with, as well as a method for toggling the visability of the seek controls. **LearnMoreCheck.java** is the first test to be finalized. The rest of the test classes are outlined with ideas or code that I would appreciate any feedback on in the branch **onceux-uiautomator-tests**.

##Changed Files
UiAutomatorBaseTest.java
* created universal setUp and tearDown methods
* created utility methods seekControls and playVideo

LearnMoreCheck.java
* created test methods that check for the presence of the Learn More text at each Ad Break.
* created utility methods learnMoreChecker and adBreakHandler to do the heavy lifting, as the only differences between tests are locations where the learn more button is checked for, and assertions that need to be made.
That's good information to present.
For now, I'd suggest standard Javadoc comments.
It might be overkill to come up with a custom Annotation class, just to identify where these methods do and don't work, but if there are other gotchas (maybe, some other JUnit feature causes Nexus 7 to melt, let's say), but we shouldn't rule it out, if Javadoc comments alone don't do the trick.
One thing that an Annotation might be able to do, that a Javadoc, can't, is to serve as a flag for build runners. This is how we prioritize our FlexRunner builds in TeamCity.