CMake: don't export turbojpeg symbols

[net147]

If an application links to both libvncserver and libjpeg-turbo (either directly or indirectly through another library), it can cause the application to unexpectedly call the libvncserver implementation instead of the libjpeg-turbo implementation.

Avoid this by not exporting the turbojpeg symbols.

Fixes #729

[bk138]

this is relying on compiler flags, there must be a CMake way, like PRIVATE linkage ...

[Micket]

Hm. I'm a bit confused as to why this source even exists here. My best understanding, libvncserver requires TurboJPEG API, but doesn't want to hard-require libjpeg-turbo itself, so instead if also supports generic libjpeg and has an old copy of libjpeg turbo's sources to build it's own.
And that seems to be used even when you are actually using libjpeg-turbo as the jpeg backend.

Options as I see it

1. Set DLLEXPORT __attribute__((visibility("hidden"))) for the vendored "mini-turbojpeg" https://github.com/LibVNC/libvncserver/blob/master/src/common/turbojpeg.h
2. Make a static library target for "mini-turbojpeg", make that PRIVATE add_library(miniturbojpeg ... + set_target_properties(minijpeg, PROPERTIES C_VISIBILITY_PRESET hidden). You have to make a target in order to actually set the generic Cmake commands, can't just do that with a source file i think.
3. Just don't use common/turbojpeg.{c,h} at all when linking to libjpeg-turbo (doesn't actually really fix the potential for exporting the symbols, but surely libjpeg-turbo is basically always used (otherwise you get a big fat warning from the cmakelists.txt) so in practice it's solved). Alternatively: Just have libjpeg-turbo as a hard requirement and drop common/turbojpeg.{c,h}?
4. Add the compiler flag as done in this pr.