HPACK Security Considerations

I have written what I think is a slightly more robust Security Consideration for HPACK.  This covers:
* the attack in the general sense, 
* how the attack might apply in HPACK and HTTP, 
* particular areas of concern, 
* how HPACK inherently mitigates these attacks, 
* what environments might need additional mitigation, and
* some suggested mitigation strategies.

Mitigation strategies that I have described are:
* actor-based isolation (a generalized application of the origin isolation principle)
* destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess
* specific protection for "special" header fields

There are a few formatting changes in the first commit, sorry.
I'm not sure I fully understand the limit set by SETTINGS_MAX_CONCURRENT_STREAMS.
For a passive attacker, once this number of requests has been reached, it needs for response to be sent and streams to be closed before having the client make new requests. This slows down the attack but may not help detecting it (its more the total number of requests, the similarity of the requests, and/or the changes in the probed value that would hint that an attack is under way).
For an active attacker, blocking packets, it could sent fake answers to close the requests, allowing more to be done. Here the client would have to detect that something is suspicious, probably by using the strategies described in the Mitigation section below.

I see three possibilities:
- Removing this paragraph entirely
- Making clear why there is a limit imposed by SETTINGS_MAX_CONCURRENT_STREAMS
- List the suspicious behaviour that could help detecting an attack is under way.