`numeric_bounds<T>` implied the argument to be an integral numeric
by requiring the `%` operation on it. This change renames `numeric_bounds`
into `numeric_integral_bounds` to emphasize that, and introduces
the `numeric_bounds` that does not support alignments and odd/even checks,
and thus works with floating point types too.

The `bounded_property` now can accept an arbitrary bounds struct that
conforms to `detail::bounds<>` concept. For compatibility purpose,
it defaults to `numeric_integral_bounds` so no code change is necessary.

While limiting the number of partitions in fetch response by
`kafka_max_bytes_per_fetch`, also consider the fetch plan's `bytes_left`
which is based on on fetch request's max_bytes and on `fetch_max_bytes`
property.

Functions down the fetch code path will need access to the local
kafka::server instance members like memory semaphores.

fix uninitialized max_service_memory_per_core, also disable metrics

Kafka server now stores (per shard) memory semaphore that will limit
memory usage by fetch request handler. Semaphore count is configured
based on the "kafka_memory_share_for_fetch" property and the kafka
rpc service memory size.

Metric `vectorized_kafka_rpc_fetch_avail_mem_bytes` added to control
the semaphore level.

There is a sharded `server` accessor in `request_context` to reach
the local shard instance of the new semaphore, as well as the local
instance of `net::memory` semaphore.

Access `replica_selector` via the newly exposed `sharded<server>`
to reach the local shard instance of `kafka::server` and its
replica_selector. This prevents cross shard access to `metadata_cache`
and future objects when replica selectors evolve.

Consult with memory semaphores on whether there is enough memory available
to perform the fetch while concurrently fetching from ntps. Both general
kafka memory semaphore, and the new kafka fetch memory semaphores
are used. With the former one, the amount consumed from it by request
memory estimator is considered.

Since batch size is not known ahead, it is estimated at 1 MiB. The first
partition in the list is fetched regardless of the semaphores values, to
satisfy the requirement that at least a signle partition from the
fetch request must advance.

The amount of units held is adjusted to the actual size used as soon as
it is known.

The acquired units of the memory semaphores are held with `read_result`
until it is destroyed at the end of the fetch request processing. When
`read_result` is destroyed in the connection shard, the semaphore units
are returned in the shard where they have been acquired.

If request's max_size bytes is more than either semaphore holds,
max_size is reduced to the memory actually available, also considering
the minimum batch size.

In kafka_server_rpfixture, an extra `kafka::server` is created using
a barely initialized `server_configuration` instance. A garbage in
`max_service_memory_per_core` has caused issues now because of the
new arithmetics done with in in the kafka::server ctor.

Test the algorithm that decides whether can a fetch request proceed
in an ntp based on the resources available.

Move the existing testing-only symbols into the `testing` ns.

RAM increased to 512M because redpanda was failing on 256M for unrelated
reasons.

Test with different values for "kafka_memory_share_for_fetch".