Fetch dependencies using FetchContent, remove conan build dependency

[jtbandes]

Alternative to #26

Instead of using conan to fetch mcap & dependencies, or getting them from rosdep (which doesn't work when we need some static-only APIs and want to control the precise dependency version), we fetch the dependency sources using FetchContent.

cc @nuclearsandwich @wep21 @emersonknapp @jhurliman, please review! Thanks 🙂

[jhurliman]

Do the usage instructions in the README need to be updated?

[wep21]

@nuclearsandwich Any thoughts on using submodules? I feel creating vendor packages is better.

[jhurliman]

@wep21 whatever approach we take, a specific version of zstd must be statically linked in. Using the existing ros2 package for the dynamically linked zstd won’t work.

[wep21]

@jhurliman Which function won't work with dynamically linked zstd? The basic functions(pkay, record, info) seem to work fine with vendor package implementation in my environment.

[jhurliman]

@wep21

https://github.com/foxglove/mcap/blob/main/cpp/mcap/include/mcap/writer.inl#L6

https://github.com/foxglove/mcap/blob/main/cpp/mcap/include/mcap/writer.inl#L258-L259

We declare ZSTD_STATIC_LINKING_ONLY and use the experimental API ZSTD_compress2(), so even if it happens to compile with a dynamically linked zstd it's not in a stable state and is liable to break with any upgrade.

We're on the ROS 2 Tooling WG call right now and an idea that was thrown out is to combine these two approaches, providing a mcap vendor package in the ROS2 ecosystem but building it using submodules or CMake FetchContent to tightly control the version of zstd we pull in and statically link against.

[jtbandes]

Updated to replace submodules with FetchContent. Another approach with a mcap_vendor package is at #28.