Add experimental VCPKG packaging

[oleg-nenashev]

Initial work for or #2 . It will not enable publishing yet, but at least ther ewill be a stable experimental build

[oleg-nenashev]

So I got stuck with the Port file pulling the pkg-config file from the root repo instead of testcontainers-c. I am not 100% sure how to make VCPKG to pull it from the right location, but maybe running the root build is a bogus approach and two CMake calls should be called for the bridge and the C Library

vscode@271be3dfe8dd:/workspaces/testcontainers-native$ cat /usr/local/vcpkg/buildtrees/testcontainers-c/install-arm64-linux-dbg-err.log
CMake Error at testcontainers-c/cmake_install.cmake:46 (file):
  file INSTALL cannot find
  "/usr/local/vcpkg/buildtrees/testcontainers-c/arm64-linux-dbg/testcontainers-c.pc":
  No such file or directory.
Call Stack (most recent call first):
  cmake_install.cmake:52 (include)

Would appreciate sanity check @seffradev

[oleg-nenashev]

That part does not work in vcpkg runs yet, even if local installation is fine.
Likely, the port files are messed up somehow

[oleg-nenashev]

I am still not sure about making testcontainers-bridge a separate deliverable, but it seems to be the easiest approach if we want to preserve the project structure. When we get to 1.0, the non-committment on the API should be explicitly documented

[seffradev]

My vision was that testcontainers-bridge would be statically linked (with -fPIC) into testcontainers-c, which would in turn be two targets, a static library, and a dynamic library.

[oleg-nenashev]

Yeah. That's easy with CMake. I just need to figure our how to do vcpkg ports in such a case, without breaking the dependency graph. Idea of having 2 packages is very debatable, maysbe I will just do twqo modes in the terstcontainers-c CMake