Add a deprecation warning to tl_expected

[christophfroehlich]

No description provided.

[christophfroehlich]

@otamachan do you support this?

[otamachan]

I'm in favor of adding a deprecation warning, but one concern: on Jazzy and Humble (both use the Humble branch of generate_parameter_library), this warning would be triggered by generate_parameter_library's headers, so users would see warnings they can't suppress from their side — until generate_parameter_library itself migrates away from tl_expected/expected.hpp. We use Jazzy, so this would affect us.

Would it make sense to add an option in generate_parameter_library's Humble branch to optionally use libexpected-dev instead? The default would keep the current behavior for backward compatibility, but
users who have libexpected-dev available could opt in to suppress the warning.

[christophfroehlich]

This is a valid concern, maybe we could even backport PickNikRobotics/generate_parameter_library#322 as it is? It will annoy users with deprecation warnings, but it could avoid breaking changes for lyrical release.
I'm also open to release jazzy+kilted from a different branch, and leave humble as it is. additional maintenance overhead is minimal I'd say.

[otamachan]

Ah, I found that the Jazzy release of RSL already uses <tl/expected.hpp> from libexpected-dev (https://github.com/ros2-gbp/rsl-release/blob/debian/jazzy/noble/rsl/include/rsl/parameter_validators.hpp#L10). RSL releases from a single branch, all distros use libexpected-dev. And since librsl.so exports to_parameter_result_msg(tl::expected<void, std::string> const&), generate_parameter_library should also use libexpected-dev to ensure ABI consistency. So backporting PickNikRobotics/generate_parameter_library#322 actually makes sense.

My only concern is that if there are existing binaries built against tl_expected/expected.hpp (vendored 1.2.0), they could have ABI mismatches with libexpected-dev.