Buildscripts/cmake for GitHub actions

[LostInKadath]

This PR offers a opportunity to build library with CMake. The process is rather clear:

1. First you should configure your project by running: cmake -S . -B .builddir from the source directory. Here you can specify the compiler, build type and several other features, that do fine tuning of your building process. Remember, that in case of gcc and clang you cannot build both debug and release binaries into one directory. You should use separate directories for every build configuration. On the other hand, msvc supports multi-config building, as it creates subfolders for each config. That's why YML-workflow on Windows slightly differs from those on Ubuntu and MacOS.

2. Then you should build the binaries: cmake --build .builddir

3. Finally you can also install the binaries: cmake --install .builddir --prefix .installdir CMake creates the file tree:

   .installdir
   ├── bin
   │   ├── h264_analyze
   │   └── svc_split
   ├── include
   │   ├── bs.h
   │   ├── h264_avcc.h
   │   ├── h264_sei.h
   │   └── h264_stream.h
   ├── lib
   │   └── libh264bitstream.a
   └── share
   └── pkgconfig
       └── libh264bitstream.pc

   PR also adds three separate workflows -- for Windows, Ubuntu and MacOS.

I've checked the building process on Windows and WSL. Unfortunately, I don't have a chance to check building on MacOS, except Github runners.

I also didn't manage to find out, how to build universal (fat) binaries on MacOS. Dumb specifying of compiler flags doesn't work on Github runners. However, these flags were specified in configure.ac for darwin9 OS -- it's a bit deprecated now. =) If it's vital, I could find the way for cross-compiling to different targets. But it may be a bit difficult -- using CMakeToolchain files, for instance.

At the moment all workflows fail on unit-tests -- that's our good old issue #52.

[LostInKadath]

Fun fact -- I had a draft branch with the same code as here. And my checks didn't fail at all. So #52 is like a Heizenbug. =)

[aizvorski]

Btw, I've seen people use cmake in this style

mkdir build && cd build && cmake .. && cmake --build .

would that also work?

[aizvorski]

One thought - we can update README.md to describe this (basically just copy-paste what you wrote in the PR) as the default build process. It's probably okay to keep the autoconf/automake files in place, but nudge people away from using them by making the cmake method the only one described in the readme.

[LostInKadath]

mkdir build && cd build && cmake .. && cmake --build . would that also work?

Sure! As for the manuals, cmake .. does the same as cmake -S .. -B .

we can update README.md to describe this as the default build process

Yeah, that would be great! Should I prepare a new README.md section, or will you do it?

[aizvorski]

It may be good to use hardened compiler options. Do you know which of these can be used for a library (without requiring the whole program to be compiled with the same options)? https://security.stackexchange.com/questions/24444/what-is-the-most-hardened-set-of-options-for-gcc-compiling-c-c

[LostInKadath]

No, I've never dealt with hardening packages before. It could be a great research.