Pull in BrowserID-Tests

Overview
=====

Import selenium tests (previously in mozilla/BrowserID-Tests), and a submodule test dependency (mozilla/bidpom), via a circuitous route. The route taken is irrelevant except in the probably rare case where we want to push or pull upstream code from mozilla/bidpom, which is a general-purpose library maintained by webqa.

This is existing code except for the new README inside the automation-tests directory and one commit that fixes some minor bugs stemming from upstream removal of selenium 1 (the RC API) code paths.

These tests can be run, today, against ephemeral instances via 123done. (And myfavoritebeers, once I fix a small, annoyingly high-impact, [bug](https://github.com/mozilla/browserid/issues/1984).)

This pull request description is pretty long because I had to jump through some annoying git hoops to come out with a configuration that met our needs.

Gory details
=========

mozilla/BrowserID-Tests has tests separated into 2 directories, 123done/ and myfavoritebeers/

These both source in mozilla/bidpom as git submodules under a directory called 'browserid', so you have a git submodule at /123done/browserid, and another (pointing at the same repo) at /myfavoritebeers/browserid. Git submodules are teh suck for branchy development, so I instead sourced bidpom using git-subtree.

In order to quickly make this git config change without write access to mozilla/BrowserID-Tests, I forked to 6a68/BrowserID-Tests, then git-subtree'd mozilla/bidpom into my fork. Then, I again used git-subtree to pull 6a68/BrowserID-Tests into 6a68/browserid. 

The net result of the git-subtreeing operations is that, from the perspective of browserid, the selenium tests inside BrowserID-Tests, and the stuff from the mozilla/bidpom repo, all just looks like normal files. However, we can still upstream to mozilla/bidpom.git, which might be useful in the future. We can probably do away with the BrowserID-Tests repo altogether, since those tests have been effectively pulled in.

### A bit about git-subtree vs git submodules

First off, warning: "git subtree" is different from "git-subtree". This ambiguity is unfortunate, as it makes googling a little tricky.

What we want is:
- to include test changes and production code changes in a single commit, for code reviewers and to keep history clean
- to be able to easily branch test code along with production code
- to be able to occasionally push or pull updates upstream (to mozilla/bidpom)

Git submodules don't track to branches; they track to commits. This makes it tricky and difficult to switch cleanly and quickly between experimental branches.

Git submodules are opaque to the super-project, so it's impossible to collect changes to super-project and submodule inside one commit, which, in our case, means code reviewers might have to traverse three repos (browserid, BrowserID-Tests, bidpom) to see related pieces of one commit. It's also a lot of annoying administrative work for the developer writing the code.

git-subtree solves both these problems. Apenwarr's [blog post](apenwarr.ca/log/?m=200904) and the git-subtree [help file](https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt) explain this really well; go have a look, if you're itnerested.

Note, git-subtree was added to mainline git in version 1.7.11 inside the contrib directory, meaning you have to install it manually. Its makefile doesn't quite work; see [here] (https://github.com/mxcl/homebrew/issues/12897#issuecomment-6751404) for instructions. (Don't worry, it's straightforward.)