[5SP, 2.5SP] GR4: Flatten block type handling in BlockRegistry and serialisation

[RalphSteinhagen]

Remove any hierarchy and maps of block types and possible instantiations from the BlockRegistry, i.e. do not separate template name (gr::blocks::type::converter) and template parameters.
Blocks will be stored as flat list of possible instantiations, e.g.

gr::blocks::type::converter::Abs<float>
gr::blocks::type::converter::Abs<double>
gr::blocks::type::converter::Abs<int32_t>
...
gr::blocks::type::converter::Abs<std::complex<float>>
...

These will be separate entries in the registry, without a nested structure that groups all gr::blocks::type::converter::Abs specialisations together. If such a grouping is wanted, it has to be recreated by users (e.g. opendigitizer UI) to meet their specific needs.

Further requirements:

• It must be possible to override the registered name by a custom fixed_string, mainly to preserve the names from using-declarations, which would be used for convenience and set useful defaults to additional template parameters/NTTPs.
  For example:

template<typename T>
using ClockSourceSystemClock = ClockSource<T, true, std::chrono::system_clock, true>;

would be registered as something like

inline auto registerClockSource = gr::registerBlock<gr::basic::ClockSourceSystemClock<uint8_t>,  
       "gr::basic::ClockSourceSystemClock">(gr::globalBlockRegistry());

• It must be guaranteed that portable types like int64_t are used in the instead of int, long, etc.

• Investigate/ensure that gr::meta::type_name() generates the same names under clang/gcc/emscripten (maybe create a simple test to detect changes between compiler versions), to ensure GRC files and GR messages are portable across architecture and compiler boundaries.

• Use the fully spelled out typenames in GRC files and GR messages (adapt examples and tests)

[frankosterfeld]

We went for types int8, ... int64, uint8 ... uint64 (no _t), float32, float64, complex, string (no std::), to make it more palatable to python users.