added unordered_node_[map|set] containers to the tutorial

doc/unordered/rationale.adoc

@@ -64,8 +64,8 @@ of bits in the hash value, so it was only used when `size_t` was 64 bit.
 
 Since release 1.79.0, https://en.wikipedia.org/wiki/Hash_function#Fibonacci_hashing[Fibonacci hashing]
 is used instead. With this implementation, the bucket number is determined
-by using `(h * m) >> (w - k)`, where `h` is the hash value, `m` is the golden
-ratio multiplied by `2^w`, `w` is the word size (32 or 64), and `2^k` is the
+by using `(h * m) >> (w - k)`, where `h` is the hash value, `m` is `2^w` divided
+by the golden ratio, `w` is the word size (32 or 64), and `2^k` is the
 number of buckets. This provides a good compromise between speed and
 distribution.
 
@@ -73,7 +73,7 @@ Since release 1.80.0, prime numbers are chosen for the number of buckets in
 tandem with sophisticated modulo arithmetic. This removes the need for "mixing"
 the result of the user's hash function as was used for release 1.79.0.
 
-== boost::unordered_flat_set and boost::unordered_flat_map
+== boost::unordered_flat_set/unordered_node_set and boost::unordered_flat_map/unordered_node_map
 
 The C++ standard specification of unordered associative containers impose
 severe limitations on permissible implementations, the most important being
@@ -81,14 +81,14 @@ that closed addressing is implicitly assumed. Slightly relaxing this specificati
 opens up the possibility of providing container variations taking full
 advantage of open-addressing techniques.
 
-The design of `boost::unordered_flat_set` and `boost::unordered_flat_map` has been
+The design of `boost::unordered_flat_set`/`unordered_node_set` and `boost::unordered_flat_map`/`unordered_node_map` has been
 guided by Peter Dimov's https://pdimov.github.io/articles/unordered_dev_plan.html[Development Plan for Boost.Unordered^].
 We discuss here the most relevant principles.
 
 === Hash function
 
 Given its rich functionality and cross-platform interoperability,
-`boost::hash` remains the default hash function of `boost::unordered_flat_set` and `boost::unordered_flat_map`.
+`boost::hash` remains the default hash function of open-addressing containers.
 As it happens, `boost::hash` for integral and other basic types does not possess
 the statistical properties required by open addressing; to cope with this,
 we implement a post-mixing stage:
@@ -98,17 +98,15 @@ we implement a post-mixing stage:
 
 where *mulx* is an _extended multiplication_ (128 bits in 64-bit architectures, 64 bits in 32-bit environments),
 and *high* and *low* are the upper and lower halves of an extended word, respectively.
-In 64-bit architectures, _C_ is the integer part of
-(1 − https://en.wikipedia.org/wiki/Golden_ratio[_φ_])·2^64^,
-whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from
-https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].
+In 64-bit architectures, _C_ is the integer part of 2^64^∕https://en.wikipedia.org/wiki/Golden_ratio[_φ_],
+whereas in 32 bits _C_ = 0xE817FB2Du has been obtained from https://arxiv.org/abs/2001.05304[Steele and Vigna (2021)^].
 
 When using a hash function directly suitable for open addressing, post-mixing can be opted out by via a dedicated <<hash_traits_hash_is_avalanching,`hash_is_avalanching`>>trait.
 `boost::hash` specializations for string types are marked as avalanching.
 
 === Platform interoperability
 
-The observable behavior of `boost::unordered_flat_set` and `boost::unordered_flat_map` is deterministically
+The observable behavior of `boost::unordered_flat_set`/`unordered_node_set` and `boost::unordered_flat_map`/`unordered_node_map` is deterministically
 identical across different compilers as long as their ``std::size_type``s are the same size and the user-provided
 hash function and equality predicate are also interoperable
 &#8212;this includes elements being ordered in exactly the same way for the same sequence of