title: Reason for boost::extension.hpp does not defining hash_value() for unordered and some other containers
body: <p>From the boost documentation:</p>
  <blockquote>
  <pre><code> It also implements the extension proposed by Peter Dimov in issue 6.18 of the Library Extension Technical Report Issues List (page 63), this adds support for:
  ...
  **the standard containers**
  ...
  </code></pre>
  </blockquote>
  <p>However, when looking at the implementation (boost version 1.71) in extension.hpp I can see that there is a specialization only for array, vector, list, deque, set, multiset, map, multimap. The other containers forward_list, unordered_set, unordered_multiset, unordered_map and unordered_multimap are missing, as well as the container adaptors stack, queue and priority_queue. While the latter seem more or less plausible (as the container behind is another one, just the interface changed), I'm at least wondering about the other containers. Are simply not yet integrated, did they get forgotten, is it because the draft does not name them as well (why?) or is there some special reason behind?</p>
  <p><strong>Notes:</strong><br>I'm aware of this question on SO<br>
  <a href="https://stackoverflow.com/questions/20039423/why-doesnt-boosthash-value-support-boostunordered-set-by-default">Why doesn't boost::hash_value support boost::unordered_set by default?</a><br>
  but I think this question is mainly asking about a set inside a set and additionally the question is 6 year old (which may lead to a different answer today), that why I'm asking this question.</p>
  <p>I'm also aware that building a hash over a complete container is neither constant access nor performant, We don't need to discuss this. Sometimes you have to change memory consumption against runtime (in this case by using boost::flyweight but this requires a hash). And if class has a container as a member, well, you're there (if you're not allowed to change the class itself).</p>