Add alternative ID support to SearchIO

With the [recent announcement](ftp://ftp.ncbi.nlm.nih.gov/blast/documents/NEWXML/ProposedBLASTXMLChanges.pdf) of a possible BLAST XML schema update and [short discussion in the mailing list](http://lists.open-bio.org/pipermail/biopython-dev/2014-March/011147.html), I decided to add support for querying for search hits using their alternative IDs to SearchIO.

In redundant databases, sometimes the same sequence may be stored multiple times under different IDs. Programs like BLAST (the only one so far, but there may be others in the future) outputs these IDs, so in principle SearchIO should also allow users to retrieve hits using one of its alternative IDs.

There are several changes contained in this pull request; some on the core SearchIO object model and some on the BLAST parsers. They are as follows:

*Changes to the core object model*

* Hit objects can be retrieved, deleted, or overwrittern from `QueryResult` objects using its primary or alternative IDs

* Alternative IDs work with `QueryResult`'s `index` and `pop`

* Alternative IDs are not counted when doing `len` nor when iterating over keys in a QueryResult object.

* Primary IDs take precedence over alternative IDs when retrieving from `QueryResult`. In other words, if one string is a primary ID for one Hit and an alternative for another, the Hit object will be that which has the string as its primary ID. 

* From a `Hit` object, alternative IDs can be retrieved using the `alt_ids` property. There is also an accompanying `alt_descriptions` property to store the descriptions of these alternative IDs.

*Changes to BLAST parsing (currently the only program that outputs alternative hit IDs)*

* blast tabular: IDs listed in the `sallseqid` after the first one considered alternative IDs
* blast XML: IDs listed in the `Hit_def` elements are considered alternative IDs (marked by `>`)
* blast text: no change, since alternative IDs are only separated by space from the previous IDs. We can come up with some clever hacks to get around this, but ultimately it will always be possible to find a case that breaks it, so I am leaving this one as it is.

*Final note*

Alternative ID support in `QueryResult` objects is implemented using an extra dictionary `__alt_hid_ids` which maps alternative IDs to a primary ID. I chose this approach so that more common operations on the dictionary storing the hits such as `len()`, `keys()` or `__iter__()` still returns the expected results (i.e. related to the primary identifiers only). While it is possible to use `_items` to contain the alternative IDs straight away, I thought that the compromise we make on making methods like `len()` work only with primary IDs will be too much. The downside of the current approach (extra dictionary) is that access to it needs to be carefully controlled to make sure alternative IDs are always up to date (see the added unit tests).

All changes come with updated test cases. Comments and suggestions welcome :).