Fixes #1320: transport adapters stored in ordered form

As suggested in [this comment](https://github.com/kennethreitz/requests/issues/1320#issuecomment-16992832), I used an OrderedDict. All tests pass on Python 2.6 - 3.3 (provided #1326 is merged for 3.2).


There's an easier way to do this with the Ordered Dictionary that doesn't require resorting the keys every time you mount an adapter. 


Is there?


After testing it, it is probably not going to be as painless as this.

:+1: Nice work @ambv 


Cool. I'm +1 as well. =)


This looks great! I'm wondering if the length should matter as much as the order in which the adapter was added, maybe. I'm assuming if you add one at any point in your process and it matches, it should be used, no?


@kennethreitz the idea behind this is that you want to ensure the longest match is the first you'll find. So if you have an adapter for `http://example.com/endpoint1` and `http://example.com` and you issue a reqeust for `http://example.com/endpoint1/resource` you're going to get the first one and find it faster. Of course for the simplest case your performance is sort of awful, but most of those cases won't see people using adapters and as Lukasa mentioned, I doubt anyone is going to have too many adapters mounted in the first place. :)


@sigmavirus24's explanation was always my understanding of how you intended transport adapters to behave. If mount-order becomes the condition, then your adapters become surprising. For instance, changing the `Session` constructor from 

``` python
s.mount('http://', HTTPAdapter())
s.mount('https://', HTTPAdapter())
```

to:

``` python
s.mount('https://', HTTPAdapter())
s.mount('http://', HTTPAdapter())
```

causes all your HTTPS traffic hits the wrong adapter. There's no functional effect because all that logic is handled underneath, but it sure is strange.


I also think having **prefixes** in the mounting API suggests using the longest matching one.


So if we do order added then we'd have to do something else when we find the adapter @kennethreitz that would be akin to what @Lukasa's last pull request did. So the benefit of ordering would make no difference.

This just ensures that any adapters you have with freakishly long prefixes are matched first and returned.


Needs a rebase :)

So, what's the status here? I'm confused :)


Rebased the PR.

The status here, as described by @sigmavirus24 in [comment 6](https://github.com/kennethreitz/requests/pull/1327#issuecomment-17009475) and confirmed by @Lukasa in [comment 7](https://github.com/kennethreitz/requests/pull/1327#issuecomment-17010424), is that the existing prefix-based `mount` syntax

``` python
  session_obj.mount('http://git', HTTPAdapter()) # 1
  session_obj.mount('http://github.com', HTTPAdapter()) # 2
  session_obj.mount('http://github.com/about/', HTTPAdapter()) # 3
```

always suggested that the longest match will be used, for example `get('http://github.com/about/us/')` will always match rule 3 (never the default http:// nor rules 1 or 2), `get('http://gittip.com')` will always match rule 1 (never the default http://), and so on.

The `mount()` invocation order does not matter, only the length of the matching prefix.


Again :+1:


:sparkles: :cake: :sparkles:


:)


:-)