That is, both `LLPointer::operator==()` and `operator!=()` and the free function
`operator==()` and `operator!=()` now accept pointer types other than the type
of the subject `LLPointer`, letting the compiler apply implicit pointer
conversions or diagnose an error.

Instead of restating the whole class, requiring changes to be made in parallel
(which has already failed), just make a template alias.

This affords strong exception safety. Also, eliminating the conditional may
improve speed.

Given templated constructors and assignment operators, it's tempting to remove
specific constructors and assignment operators with the same LLPointer<Type>
parameters. That turns out to be a mistake. Add comments to warn future
maintainers.

Generalize LLPointer's comparison operators to allow comparable LLPointer types.

In C++20, `std::filesystem::u8path()` (that accepts a UTF-8 encoded
`std::string` and returns a `std::filesystem::path`) is deprecated. Instead,
to engage UTF-8 coding conversions, we're supposed to pass the `path`
constructor a `std::u8string`, i.e. a `std::basic_string<char8_t>`. Since
`char8_t` is a type distinct from both `char` and `unsigned char`, we must Do
Something to pass a UTF-8 encoded `std::string` into `std::filesystem::path`.

To avoid copying characters from a `std::string` into a temporary
`std::u8string` and from there into the `std::filesystem::path`, make a
`boost::transform_iterator` that accepts a `std::string_view::iterator` and
adapts it to dereference `char8_t` characters. Make `fsyspath(std::string_view)`
engage the base-class constructor accepting (iterator, iterator), adapting
`string_view::begin()` and `end()` to deliver `char8_t` characters.

Use the same tactic for `fsyspath::operator=(std::string_view)`, explicitly
calling `std::filesystem::path::assign()` with the adapted iterators.

To resolve ambiguities, provide both constructors and assignment operators
accepting `(const std::string&)` and `(const char*)`, explicitly converting
each to `std::string_view`.

At the same time, `std::filesystem::path::u8string()` now returns
`std::u8string` rather than `std::string`. Since `std::filesystem::path`
delivers only that `std::u8string` rather than iterators into its internal
representation, we can't avoid capturing it and copying to the returned
`std::string`.

Remove explicit `.u8string()` calls from a few existing `fsyspath` instances,
now that `fsyspath` supports implicit conversion to `std::string`.

GCC on Linux complains that "math.h", which hoists all the standard library
math functions into the global namespace for classic C compatibility, creates
a conflict between `std::lerp()` and the `lerp()` function in llmath.h.
(Perhaps we should just replace our `lerp()` definition with `using std::lerp;`)

Anyway, bringing in <cmath> rather than "math.h" leaves standard library math
functions in the `std` namespace, avoiding the conflict.

Hoist `std::lerp()` into the global namespace instead.

`LLKeyData::operator==(const LLKeyData&)` and `operator!=(const LLKeyData&)`
were not themselves `const` methods. In C++20, that can produce a fatal
warning that if the compare operands were reversed, you'd get different
results. Making them both `const` should fix it.

While touching the method definitions, make `operator==()` more intuitive, and
make `operator!=()` simply negate `operator==()` instead of restating it in
reverse.

For reasons that remain unclear, MSVC likes our lerp() function better than
its own std::lerp() function: publishing the latter into the global namespace,
instead of defining our own, produces fatal argument conversion warnings.

"math.h" publishes all of <cmath> into the global namespace, which causes a
GCC conflict between std::lerp() and our lerp() function. Including <cmath>
instead leaves std::lerp() in the std namespace, eliminating the conflict.

Now the lerp() in global namespace is std::lerp(), but it remains true that
for some calls to std::lerp(), MSVC issues fatal argument conversion warnings.
In those places, call flerp() (our historic lerp()) instead.

This allows removing #include "llerror.h" from llpointer.h.
Also remove #include "llmutex.h" as a heavy way to get
<boost/functional/hash.hpp>.

That requires adding #include "llmutex.h" to llimage.h, llnotifications.h,
llwatchdog.cpp and llvolumemgr.cpp, which were inheriting it from llpointer.h.

Instead of using strdup() and free() to store comment_text in JPEG2KEncode,
store a std::string. Similarly, instead of manually managing pointers to
encoder, decoder, image, stream and codestream_info in JPEG2KDecode and
JPEG2KEncode, use std::unique_ptr for each, specifying their respective
deleter functions.

owning_ptr<T> adapts std::unique_ptr<T> to be a better drop-in replacement for
a legacy class that formerly stored plain T* data members, and explicitly
destroyed them using domain-specific destructor functions.

Directly substituting std::unique_ptr into JPEG2KEncode and JPEG2KDecode was
cumbersome because every such pointer declaration required a redundant
template parameter describing the deleter function passed into its
constructor. Moreover, it required lots of little syntax tweaks: changing
every assignment to a reset() call, changing every reference to a get() call.

Using owning_ptr<T> allows us to leave the code more or less as it was before,
save that assignment and destruction automatically handle the previous
referenced T instance.

Clean up llpointer.h per previous discussions.