build: enable Seastar to build shared and static libs in a single build

before this change, we respect the CMake variable named
`BUILD_SHARED_LIBS`, and build shared libraries if it is set, build
static libraries otherwise. but this model cannot fulfill the needs
of a parent project which needs to build both static and shared
seastar libraries with different configuration in a multi-config
generator settings. as `BUILD_SHARED_LIBS` is a CMake variable which
cannot be changed at build time, and hence cannot be assigned with
different values using generator expression.

so, in this change, we add two options

- Seastar_BUILD_STATIC_LIBS
- Seastar_BUILD_SHARED_LIBS

to configure if the build should generated static libraries and
shared libraries respectively. but `BUILD_SHARED_LIBS` is still
supported, and the behavior is backward compatible. the only
user-visible differences are, the libraries of

- seastar
- seastar_testing
- seastar_perf_testing

are now aliases of the targets which builds the static or shared
libraries. so one cannot build "seastar" as a target anymore,
but should specify which library to build:

```
$ cmake --build build --target seastar # does not work anymore
$ cmake --build build --target seastar-static
$ cmake --build build --target seastar-shared
```

the reason is the limit of an ALIAS library, which cannot be used
as a target. but we still need to use a non-interface library
to generate .pc file, where, for instance, we use
`$<TARGET_FILE_NAME:seastar_testing>` for the library list of a
certain Seastar library.

but a CMake-based project including seastar can still link against
it using "seastar" as a library.

please note, in d8a70b3, we pass `--ftls-mode=initial-exec` when
building the tree, to address the problem of recursive call of malloc
when using seastar allocator. but we cannot use different compiling
options when building both shared libraries and static libraries, so
we always pass this option as long as `BUILD_SHARED_LIBS` OR
`Seastar_BUILD_SHARED_LIBS` is set *and* when we are building
dev/release modes. as these two modes enables the seastar allocator.
this should not hurt the overall performance, as we are not using
global-dynamic mode, but initial-exec. this is verified using
```console
$ cmake \
  -DCMAKE_CONFIGURATION_TYPES="Debug;RelWithDebInfo" \
  -DCMAKE_CROSS_CONFIGS="Debug;RelWithDebInfo" \
  -DCMAKE_DEFAULT_CONFIGS="Debug;RelWithDebInfo" \
  -DSeastar_BUILD_SHARED_LIBS=ON \
  -DSeastar_BUILD_STATIC_LIBS=ON  \
  -G "Ninja Multi-Config" -B build -S .
$ cmake --build build --config RelWithDebInfo --target seastar-static
$ readelf -r
build/CMakeFiles/seastar-objects.dir/RelWithDebInfo/src/core/reactor.cc.o| \
  grep -i tls | tr -s ' ' | cut -d' ' -f 3,5 | uniq
R_X86_64_TPOFF32 __tls_guard
R_X86_64_PLT32 _ZStlsRSoRKNSt15_[...]
```

and

```console
$ cmake -DCMAKE_BUILD_TYPE="RelWithDebInfo" -G "Ninja" -B build -S .
$ cmake --build build --target seastar-static
$ readelf -r build/CMakeFiles/seastar-objects.dir/src/core/reactor.cc.o| \
  grep -i tls | tr -s ' ' | cut -d' ' -f 3,5 | uniq
R_X86_64_TPOFF32 __tls_guard
R_X86_64_PLT32 _ZStlsRSoRKNSt15_[...]
```

so the TLS variables are using "TPOFF32" relocation type, in general,
it implies the initial-exec TLS model. the PLT32 is not specific TLS,
it's more related to external symbols linkages.

Refs scylladb/scylladb#2717
Signed-off-by: Kefu Chai <[email protected]>