json_view: keep GCC's inlining of view walks with the diagnostics macros

Measured on GCC 13 (x86-64) with JSON_DIAGNOSTICS or JSON_DIAGNOSTIC_POSITIONS,
a recursive walk over a view took 2.7 to 2.9 times the instructions: GCC no
longer inlined the walk into itself. The cause was not the walk's code but
that the path and range code of errors.hpp was instantiated in every
translation unit (the non-template throw helpers referenced it), which
changed GCC's early inlining of unrelated view functions. diagnostics() and
the throw helpers that take an error_site are now templates, so that code is
instantiated only where an exception can be thrown; the walks have the
instruction counts of develop again.

Iterators no longer keep their container: with it, one walk was still 1.1 %
slower. key() of an iterator over an array or a primitive value
(invalid_iterator.207) is therefore thrown without a context, as documented.

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

docs/mkdocs/docs/features/json_view.md

@@ -138,7 +138,9 @@ document: `#!cpp auto v = json_document::parse(text).root();` does not compile.
   [`JSON_DIAGNOSTIC_POSITIONS`](../api/macros/json_diagnostic_positions.md), the exceptions of views name the path
   and the bytes of the value as those of `#!cpp basic_json` do; as a view has neither parent pointers nor stored
   positions, both are found from the document's index when the exception is thrown, which takes time linear in the
-  size of the document (only for an exception). The other macros only affect the values `materialize()` produces,
+  size of the document (only for an exception). One exception has neither: `key()` of an iterator over an array or a
+  primitive value ([`invalid_iterator.207`](../home/exceptions.md#jsonexceptioninvalid_iterator207)), as a view's
+  iterator does not know the value it iterates over. The other macros only affect the values `materialize()` produces,
   through `BasicJsonType`.
 
 ## What is different