hashmap: add OrderedHashmap as a distinct type

Few Hashmaps/Sets need to remember the insertion order. Most don't care
about the order when iterating. It would be possible to use more compact
hashmap storage in the latter cases.

Add OrderedHashmap as a distinct type from Hashmap, with functions
prefixed with "ordered_". For now, the functions are nothing more than
inline wrappers for plain Hashmap functions.
test: generate tests for OrderedHashmap from Hashmap tests

test-hashmap-ordered.c is generated from test-hashmap-plain.c simply by
substituting "ordered_hashmap" for "hashmap" etc.

In the cases where tests rely on the order of entries, a distinction
between plain and ordered hashmaps is made using the ORDERED macro,
which is defined only for test-hashmap-ordered.c.
test: add and improve hashmap tests

Test more corner cases and error states in several tests.

Add new tests for:
  hashmap_move
  hashmap_remove
  hashmap_remove2
  hashmap_remove_value
  hashmap_remove_and_replace
  hashmap_get2
  hashmap_first

In test_hashmap_many additionally test with an intentionally bad hash
function.
hashmap: hashmap_move_one() should return -ENOENT when 'other' is NULL

-ENOENT is the same return value as if 'other' were an allocated hashmap
that does not contain the key. A NULL hashmap is a possible way of
expressing a hashmap that contains no key.
hashmap: drop assert(h) from hashmap_next()

It's handled just fine by returning NULL.
install: make InstallContext::{will_install,have_installed} OrderedHashmaps

It appears order may matter here. Use OrderedHashmaps to be safe.
journal: make JournalFile::chain_cache an OrderedHashmap

The order of entries may matter here. Oldest entries are evicted first
when the cache is full.

(Though I don't see anything to rejuvenate entries on cache hits.)
journal: make Server::user_journals an OrderedHashmap

Order matters here. It replaces oldest entries first when
USER_JOURNALS_MAX is reached.
journal: make sd_journal::files a OrderedHashmap

Anything that uses hashmap_next() almost certainly cares about the order
and needs to be an OrderedHashmap.
sd-bus: make sd_bus::reply_callbacks a OrderedHashmap

The way process_closing() picks the first entry from reply_callbacks
and works with it makes it likely that it cares about the order.
resolve: make DnsScope::conflict_queue an OrderedHashmap

on_conflict_dispatch() uses hashmap_steal_first() and then does
something non-trivial with it. It may care about the order.
shared: split mempool implementation from hashmaps
hashmap: return more information from resize_buckets()

Return 0 if no resize was needed, 1 if successfully resized and
negative on error.
hashmap: introduce hashmap_reserve()

With the current hashmap implementation that uses chaining, placing a
reservation can serve two purposes:
 - To optimize putting of entries if the number of entries to put is
   known. The reservation allocates buckets, so later resizing can be
   avoided.
 - To avoid having very long bucket chains after using
   hashmap_move(_one).

In an alternative hashmap implementation it will serve an additional
purpose:
 - To guarantee a subsequent hashmap_move(_one) will not fail with
   -ENOMEM (this never happens in the current implementation).
test: add test for hashmap_reserve()
install, cgtop: adjust hashmap_move_one() callers for -ENOMEM possibility

That hashmap_move_one() currently cannot fail with -ENOMEM is an
implementation detail, which is not possible to guarantee in general.
Hashmap implementations based on anything else than chaining of
individual entries may have to allocate.

hashmap_move_one will not fail with -ENOMEM if a proper reservation has
been made beforehand. Use reservations in install.c.

In cgtop.c simply propagate the error instead of asserting.
unit: place reservations before merging other's dependencies

With the hashmap implementation that uses chaining the reservations
merely ensure that the merging won't result in long bucket chains.

With a future alternative implementation it will additionally reserve
memory to make sure the merging won't fail.
hashmap: allow hashmap_move() to fail

It cannot fail in the current hashmap implementation, but it may fail in
alternative implementations (unless a sufficiently large reservation has
been placed beforehand).
unit: adjust for the possibility of set_move() failing