create test runner specific Test Base classes and Watchers

[titusfortner]

This PR is a stepping stone for pulling out some of these files and creating new jar files. Once implemented, they'll be deleted from this project and imported as a dependency.

For Sauce Bindings 1.2(?) we want to be able to create Test Runner specific helper classes.
One benefit is we can auto generate test name if it isn't already defined.
Another benefit is just less boiler plate code for the user.

My goal is to create
sauce-bindings-junit.jar with JUnitBase.java and SauceTestWatcher
and
sauce-bindings-testng.jar with TestNGBase.java

You can take a look at the two TestBase.java files below to see what would be required by end users with this approach.
Also, note that if you just want defaults your tests can extend JUnitBase or TestNGBase directly.

What do you think of this approach?

[nadvolod]

This is looking nice for me @titusfortner . Just to make sure we're on the same page. You're planning to have the user override the updateOptions() which will allow them to do something specific that they need? In your example that's setting build name. But what if they want to set browser options for example?
Also, would it be wise for us to also set the build name automatically, without forcing the user to do it?

[titusfortner]

You're planning to have the user override the updateOptions()

Yes exactly. It is optional, but likely necessary. With JUnit you can just update what is in option instance variable. With TestNG, you have to pass it in and return it since ThreadLocal. Actually, we can probably do the same thing with TestNG and just require getOption() instead of option that might be better actually.

As for specifying build name... yeah, that gets confusing. Build Name is being overridden here because when running locally with the make file , it runs the tests in separate builds. It's kind of designed to demo/run locally, not on a CI, which wouldn't have that problem. It probably needs a conditional for when it does run on CI. It probably makes sense to pull that out into customBuildName() or something. I can figure out how to optimize it.