Fix contradictions between the documentation, the README, and the library (#5825)

- Discarded values: the legacy macro only changes <= and >=; != is true by default
- Out-of-range numbers are rejected while parsing, not stored as NaN
- merge_diff round trip: point to the ordered_json caveat
- ensure_ascii example shows the escaped output
- out_of_range.405 is thrown for "remove"/"move" on the root, not "add"
- CBOR stores binary subtypes as tags
- Integer/float comparison uses exact values, not conversion
- diff, flatten, and the binary writers are depth-bounded
- FAQ: max_digits10 for serialization, trailing commas are supported
- out_of_range.407 is still thrown by to_bon8
- FetchContent_MakeAvailable needs CMake 3.14
- json_fwd.hpp contents, operator< link, RFC 7396 for merge patch
- README: dump() wording, merge_diff, MSYS2/build2, patch comment typos,
  operator[] link, embedded CMake example aligned with the docs

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

docs/mkdocs/docs/features/binary_values.md

@@ -267,9 +267,10 @@ unsigned 8-bit integer. If no subtype is given, the generic binary subtype 0x00
 
 ### CBOR
 
-[CBOR](binary_formats/cbor.md) supports binary values, but no subtypes. Subtypes will be serialized as tags. Any binary
-value will be serialized as byte strings. The library will choose the smallest representation using the length of the
-byte array.
+[CBOR](binary_formats/cbor.md) supports binary values and subtypes. Any binary value will be serialized as a byte
+string; a subtype is serialized as a tag preceding it. When parsing, tags are only read back as subtypes with
+`cbor_tag_handler_t::store` (see [`from_cbor`](../api/basic_json/from_cbor.md)). The library will choose the smallest
+representation using the length of the byte array.
 
 ??? example "Example: serialize a binary value to CBOR"
 

docs/mkdocs/docs/features/macros.md

@@ -243,9 +243,9 @@ See [full documentation of `JSON_USE_GLOBAL_UDLS`](../api/macros/json_use_global
 
 ## `JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON`
 
-When defined to `1`, the library restores the legacy behavior in which a discarded value compared equal to itself. This
-behavior is [deprecated](../integration/migration_guide.md#miscellaneous-functions) and switched off (`0`) by
-default.
+When defined to `1`, the library restores the legacy behavior in which comparing a discarded value with `<=` or `>=`
+yields `#!cpp true` instead of `#!cpp false`. This behavior is
+[deprecated](../integration/migration_guide.md#miscellaneous-functions) and switched off (`0`) by default.
 
 See [full documentation of `JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON`](../api/macros/json_use_legacy_discarded_value_comparison.md).
 

docs/mkdocs/docs/features/merge_patch.md

@@ -1,6 +1,6 @@
 # JSON Merge Patch
 
-The library supports JSON Merge Patch ([RFC 7386](https://tools.ietf.org/html/rfc7386)) as a patch format.
+The library supports JSON Merge Patch ([RFC 7396](https://tools.ietf.org/html/rfc7396)) as a patch format.
 The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of
 modifications to a target resource's content. This function applies a merge patch to the current JSON value.
 

docs/mkdocs/docs/features/modifying_values.md

@@ -66,7 +66,7 @@ config.update(user_settings, true);
 // {"log":{"file":"app.log","level":"debug"},"retries":3}
 ```
 
-[JSON Merge Patch](merge_patch.md) ([RFC 7386](https://tools.ietf.org/html/rfc7386)) also merges objects recursively,
+[JSON Merge Patch](merge_patch.md) ([RFC 7396](https://tools.ietf.org/html/rfc7396)) also merges objects recursively,
 but it is a different tool: a `#!json null` in the patch means "remove this key". It is meant for applying merge patch
 documents (e.g., received via HTTP PATCH). To merge configuration-like objects, use `#!cpp update(..., true)`. To apply
 a sequence of well-defined edit operations, see [JSON Patch](json_patch.md).
@@ -90,6 +90,6 @@ a.erase(1);             // [1,3,4]  (erase by index)
 - [`push_back`](../api/basic_json/push_back.md) / [`emplace_back`](../api/basic_json/emplace_back.md) - append to an array
 - [`emplace`](../api/basic_json/emplace.md) - insert into an object if the key is absent
 - [`update`](../api/basic_json/update.md) - merge objects (shallow, or recursive with `merge_objects`)
-- [`merge_patch`](../api/basic_json/merge_patch.md) - apply an RFC 7386 merge patch
+- [`merge_patch`](../api/basic_json/merge_patch.md) - apply an RFC 7396 merge patch
 - [`erase`](../api/basic_json/erase.md) / [`clear`](../api/basic_json/clear.md) - remove elements
 - [JSON Patch and Diff](json_patch.md) and [JSON Merge Patch](merge_patch.md) - structured modifications

docs/mkdocs/docs/features/parsing/untrusted_input.md

@@ -50,19 +50,13 @@ stack, however deeply it is nested.
 
 Once a value has been parsed, operations that walk it recursively -- serializing it with
 [`dump`](../../api/basic_json/dump.md), hashing it, copying it, comparing two values with `#!cpp ==`, `#!cpp <`, or (in
-C++20) `#!cpp <=>`, merging with [`update`](../../api/basic_json/update.md), and applying a
-[`merge_patch`](../../api/basic_json/merge_patch.md) -- descend at most 128 levels on the call stack and continue
+C++20) `#!cpp <=>`, merging with [`update`](../../api/basic_json/update.md), applying a
+[`merge_patch`](../../api/basic_json/merge_patch.md), creating a patch with [`diff`](../../api/basic_json/diff.md) or
+[`merge_diff`](../../api/basic_json/merge_diff.md), [`flatten`](../../api/basic_json/flatten.md), and the binary
+writers (`to_cbor`, `to_msgpack`, ...) -- descend at most 128 levels on the call stack and continue
 below that with an explicit stack instead, so none of them can exhaust the stack either, however deeply the value is
 nested. Destroying a value (its destructor) never recurses at all, regardless of nesting depth, for the same reason.
 
-!!! note "Not every operation is bounded yet"
-
-    [`diff`](../../api/basic_json/diff.md), [`flatten`](../../api/basic_json/flatten.md), and the binary writers
-    (`to_cbor`, `to_msgpack`, ...) still recurse once per nesting level; this is called out as work in progress in the
-    [assurance case](../../community/assurance_case.md#secure-design). A value deep enough to matter for these
-    operations would typically first have to survive parsing without hitting a self-imposed depth limit, as described
-    above.
-
 ## Input size
 
 The library does not limit the overall size of a JSON text; a value nested or wide enough will use memory

docs/mkdocs/docs/features/serialization.md

@@ -52,7 +52,7 @@ with `\uXXXX` sequences, so that the output contains only ASCII characters:
 ```cpp
 json j = "苹果";
 j.dump();               // "苹果"
-j.dump(-1, ' ', true);  // "苹果"
+j.dump(-1, ' ', true);  // "\u82f9\u679c"
 ```
 
 ## Handling invalid UTF-8

docs/mkdocs/docs/features/types/index.md

@@ -281,7 +281,7 @@ As this range is a subrange of the exactly supported range [`INT64_MIN`, `INT64_
 
 > This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.
 
-This implementation does exactly follow this approach, as it uses double precision floating-point numbers. Note values smaller than `#!c -1.79769313486232e+308` and values greater than `#!c 1.79769313486232e+308` will be stored as NaN internally and be serialized to `#!json null`.
+This implementation does exactly follow this approach, as it uses double precision floating-point numbers. Note that numbers smaller than `#!c -1.79769313486232e+308` or greater than `#!c 1.79769313486232e+308` are rejected during parsing with [`out_of_range.406`](../../home/exceptions.md#jsonexceptionout_of_range406). Non-finite values (NaN and infinity) can only be stored by assigning them directly and are serialized to `#!json null`.
 
 ### Storage