RFC: consider linking the CLI tool against the shared library

Split out from #2950

Currently, the official Makefiles statically link the CLI tool `zstd` against the library objects. This has an immediately crucial purpose: the tool links against some private symbols.

It would be interesting to consider optionally linking against the shared library instead. The private symbols can be refactored into an internal utility library called, for the sake of argument, `libcommon.a`, and linked to both the shared library and to the program(s) that need it.

This has a couple of advantages:
- keep installation size down, which isn't a huge deal in most cases (but use cases vary)
- distros like it due to $REASONS
- for code organization purposes, it helps to distinguish between what is expected to be used by internal utilities, and what isn't -- and avoid possibly leaking the entirety of libzstd's internals to the in-tree binaries
- it may occasionally find code that doesn't belong there and wasn't supposed to do anything, but nevertheless does, as in #2950 :D

An existing implementation of this concept is already present in meson.build -- and this originally worked because meson didn't implement the `-fvisibility` settings the Makefile did. I fixed that, and in the process had to unpack the objects from the shared library and link them individually to the CLI tool and to test utilities.

Meson's built-in option `-Ddefault_library={static|shared|both}` determines whether to build the shared and/or static libraries, and then the program will be linked to whichever the user chose.

However, it becomes a bit complicated and undocumented to figure out which object files need to be linked in on top of libzstd itself. Making this officially supported in the Makefile build would be neat.