Refactor: concat() is constexpr and can deal with std::array<>

[reneme]

This reworks the concat() helper, giving it similar smartness as load_le and friends. Most notably, it is now constexpr and gains support for statically sized containers (std::array<> and std::span<T, size>). Also, the desired output container can now be defined without using the (now removed) concat_as<> crutch.

The output container to use is determined along the following rules:

1. explicitly specified by the caller: concat<std::vector<uint8_t>>(...) or concat<std::array<uint8_t, 32>>(...),
2. if all input containers have static extent, the output container is a std::array with the appropriate size,
3. if the first input container is dynamically allocated, use this one (that's how the old concat handled it),
4. fail compilation and urge the caller to explicitly specify an output container.

Example usages:

constexpr std::array<uint8_t, 4> a1{1,2,3,4};
constexpr std::array<uint8_t, 2> a2{5,6};
std::vector<uint8_t> v1{7,8,9};

constexpr std::array<uint_8_t, 6> c1 = concat(a1,a2); // {1,2,3,4,4,5}
std::vector<uint8_t> c2 = concat(v1, a2);             // {7,8,9,5,6}
auto c3 = concat<std::array<uint8_t, 4>>(v1, a2);     // runtime exception: size mismatch (4 != 5)
auto c4 = concat<StrongVector>(v1, a1);               // {7,8,9,1,2,3,4}
// ...

Currently, this implementation cannot handle range elements of move-only types (as it uses std::copy() internally). Technically, this could probably be resolved, but I refrained from doing that as we mostly concatenate strings anyway. Nevertheless, its worth to keep that in mind and extend it when necessary.

[coveralls]

coverage: 92.028% (+0.008%) from 92.02%
when pulling d324f9f on Rohde-Schwarz:refactor/concat_helper
into 846a6ae on randombit:master.

[randombit]

This is really nice, thanks.

Left one technical question just for my own understanding.

Also I noticed in the library src itself you avoid using the autodetection, instead always specifying the output type. Is there a reason for this?

[randombit]

What's up with this?

[reneme]

That's a default value, if the parameter pack (T0) is empty.

[reneme]

Also I noticed in the library src itself you avoid using the autodetection, instead always specifying the output type. Is there a reason for this?

The changes in this pull request in the usage locations remove the concat_as<> overload. That might give this impression. However, concat_as<> was specifically added to allow overriding the auto-detected default: mostly because the first component had an unfavorable type. Now, with the addition of the AutoDetect meta-type we don't need a dedicated "override" function anymore.

There are plenty places where no explicit out-type is given, they just don't show up in this diff.