feat: C/C++ providers

[aleksrutins]

Closes #164

This PR adds a few providers:

• ROS
• CMake/Meson

[coffee-cup]

Thoughts on combining the providers into a single one that switches based on how its built. Having 3 top level providers and docs pages is a lot for c++

Also do users who build with c++ typically deploy without any Dockerfile? I'm not familiar with the c++ world when it comes to servers, but worry these providers would get very low use and become out of date quickly. Is this something you actively deploy with?

[aleksrutins]

Based on #164 and looking around based on that, it seems that Docker images are a relatively common way to package ROS packages, and normally that requires a decent bit of setup. As far as the other providers, I'd use the CMake provider. The Meson provider I'd probably also use, just not as often. They should all be relatively easy to keep up to date - the CMake and Meson providers default to just the latest versions, and so shouldn't require much maintenance at all, and all the ROS provider should need is an occasional base image update.

As far as merging the providers, I'd be willing to do that for the Meson and CMake providers - the ROS provider, though, is a completely different beast, so I'd rather keep it separate.

[iloveitaly]

@aleksrutins thanks for your amazing work here and sorry for the delay!

We decided not to support ROS. I'd never heard of it before—looks like a super cool framework—but I don't see a way any cloud provider is going host a ROS project. We should make it more clear that Railpack is focused on building containers for cloud deployment and not on-device images.

The C++ provider looks great. If you can remove the ROS provider + docs, I can get the C++ support merged.

[aleksrutins]

Weirdly enough, the snapshots succeed on my machine.