Migrate WebDriver feature tests to the point-of-use

[jason0x43]

Currently Intern's webdriver code performs a battery of feature tests when a session is started to determine which commands are broken and whether some follow the JWP or W3C standard. These tests are necessary for Intern to provide a consistent experience across different browsers. However, they are slow and often confusing to users since it may appear that unknown tests are running. They also perform unnecessary work since users may only use a fraction of the commands being tested.

Instead, Intern should set feature flags if and when commands fail. The basic pattern should be:

1. Try a command
2. If it fails in a way that suggests it's broken (InvalidCommand, UnknownCommand, etc.) and fallback logic exists and a feature flag hasn't already been set (i.e., the flag is undefined), then set the flag and recursively call the same method.
3. If the recursive call fails, let the error propagate

command() {
  if (this.capabilities.commandIsBroken) {
    return this.execute('fallback logic');
  } else {
    return this.serverPost('/command').catch(error => {
      if (/* error is a command failure */) {
        this.capabilities.commandIsBroken = true;
        return this.command();
      }
      throw error;
    });
  }
}

The above strategy could be tweaked if there are multiple levels of fallback logic (maybe from W3C -> JWP -> JS emulation).

Note that some up-front feature tests may still be needed; there are cases where calling certain commands, particularly with IE, Safari, and some versions of geckodriver, can completely hang a remote browser. These are documented in the Leadfoot source. Flags for those features are set without running tests, and should continue to be set this way.

This issue is related to #1105, which may affect the set of capability flags that Intern uses.

See #1046

[jason0x43]

We'll need to work out a pattern for tests. Some tests look at pre-set features to decide whether to skip the test so as to avoid testing features that are known not to work.

[aciccarello]

Some notes from my initial pass at this:

• A lot of the capabilities in discoverServerFeature don't seem to be used anywhere.
• Figuring out how to know that an error is because the feature isn't supported will probably need to be validated on all platforms.
• Some of the capabilities are used multiple places so we should have a way to reuse any logic to check if the capability is working.