removed get/set speed functions
Carp on use of get|set_speed about ensuing removal
Update generated travis.yml to address CI failures

There's a new version of the Dist::Zilla::Plugin::TravisYML dzil plugin
- we're hoping it speeds up our CI runs and gets them passing
again. Most of the CI runs were actually failing while trying to install
Dist::Zilla and its dependencies, and not even making it to S::R::D's
tests, which was frustrating.
Try out some Travis options to avoid unnecessary tests
Try out fixes in 3c8e91f against all perl versions
Limit perl versions that are run on Travis
Cleanup whitespace in 01-driver.t
Use DI to inject error handler in RemoteConnection

This allows appium/perl-client to use its own error handler as of
S::R::D v0.2150
Move unregistered portion of driver.t testing to the bottom

The majority of the 01-driver.t test runs against a set of recorded HTTP
request/response pairs. To get a no server response message, we
unregister the PSGI takeover and get access to normal HTTP traffic. But,
we only want to unregister when we no longer need the recorded
pairs. The storage tests do need the recorded pairs, so that test should
go first; alternatively, this test should go last.
Use $self->FINDERS to allow for modification in inherited classes

Appium has a different list of FINDERS strategies than
Webdriver. Although we can read the FINDERS constant from inherited
classes, I do not believe we can change it from there without having to
overwrite the subroutine in S::R::D's Driver.pm, as the `find_element*`
functions were hardwired to use their FINDERS constant only. Now, they
look for the FINDERS sub on $self, and we can provide a different
FINDERS in inherited classes.
Verify error cases when no server can be located
Handle the Saucelabs error message error case

There is some complicated stuff going on in RemoteConnection.pm's
`_process_response` and Driver.pm's `execute_command`. `_process_response`
sends back different data structures depending on a couple flags, like
status code, whether or not the response is json, etc
etc. `execute_command` unwinds that logic in Driver.pm in order to get at
the necessary messaging or values, as may be the case.

But, when starting up a new session via Driver.pm's
_request_new_session, we do not use the `execute_command` subroutine to
to send the request and handle the response, so we lose out on that
complicated unwinding. This leads to things like error messages from
Saucelabs not showing up because the return value from `_process_response`
is of an unexpected structure.

There is some risk to this, as the error branches in `_process_response`
are used in every front-facing Driver.pm subroutine, but it should be
properly handled in `execute_command` by this portion:

    elsif ( $resp->{cmd_return} ) {
        if ( ref( $resp->{cmd_return} ) eq 'HASH' ) {
            $msg .= ": $resp->{cmd_return}->{error}->{msg}"
              if $resp->{cmd_return}->{error}->{msg};
            $msg .= ": $resp->{cmd_return}->{message}"
              if $resp->{cmd_return}->{message};
        }
        else {
            $msg .= ": $resp->{cmd_return}";
        }
    }
    croak $msg;
Fix #152: Ensure consistent error messaging

This came out of an email discussion where the error message for trying
to start Chromedriver without having previously configured your selenium
server was unhelpful. As per #152, we want to be sure not to muck up the
current error message, as users may rightly be depending on it. So,
we lock it down with a test.
Update generated cpanfile dependencies
Update os x and linux recordings; gear up for 0.2150 release
Update changes file with recent modifications

[skip ci] No code changes in this commit...