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.
Yes, this is fairly tricky, and I'm not sure how to best explain this one.  It is important though.  One of the key considerations in any attack of this sort is whether the attack can be detected.  If it can be detected, then measures can be taken.

In this attack, the attacker allows for the header table to be primed without interference from the attacker, allowing packets to pass normally.  Then, when they start guessing, they block further progress, which does not prevent a client from initiating more requests, until they reach SETTINGS_MAX_CONCURRENT_STREAMS, after which the client needs to receive feedback from the server to continue.

I also just realized that this limit is only effective for client-based attacks.  An attack by a server is limited only to 2^30 attempts, since PUSH_PROMISE isn't limited in the same way.

Note also that the TCP congestion window doesn't limit the attack, because the attacker can forge TCP acknowledgements.

I will expand on this.