## Rationale:

We have to manually do this currently even while it should be part of the handshake.

This leads to ignorance of this feature, and chrome not working due to a missing header when testing only in firefox (which ignores if none of sent subprotocols come back)

## Implementation and usage:

I’m adding a kwarg to `do_handshake` which allows the user to specifiy subprotocols his/her client speaks. `do_handshake` returns an additional header with the chosen protocol if the handshake is successful. This doesn’t break the API in any way.

If the server speaks any of the supplied subprotocols, the first protocol spoken by both is selected from the the client-supplied list, else the handshake fails. Essentially this means that you order the `protocols` sequence by preference: best protocol first, worst last.

## Open Questions:

1. The agreed-upon protocol is valuable information not only for the Server, but the user: If we speak multiple protocols, we want to know which one the handshake selected. The user has to extract it from the headers, which are simply a sequence and no dict, making this impractical.

    Should we change the response tuple to include the protocol as fifth mamber? This would break unpacking assignments like this:

        ```python
        >>> code, response_headers, parser, writer = do_handshake('get', headers, transport)
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        ValueError: too many values to unpack (expected 4)
        ```

        We could also return something unpackable to 4 elemets that also has a “protocol” field, but that would make the code more complex (tuples are very useful to avoid creating Java-style result-classes).

2. Autobahn|Python forbids duplicate mentions of protocols in the comma-separated list sent by the server. Should we also fail the handshake when this happens or be more lenient?