mark YUV encodings as deprecated

[christianrauch]

#214 introduced new encoding names uyvy and yuyv as replacement for yuv422 and yuv422_yuy2. This PR marks those replaced encodings as deprecated with a hint which encoding to use instead and removes their usage in this repo.

[tfoote]

Marking these as deprecated I think makes sense, but we need to have a transition time before they are removed from the implementation as removing them from the implementation will break any current users. The cost of keeping these is moderately low so we should consider a moderately long deprecation cycle. More than just the minimum one release cycle.

[christianrauch]

The CI marks this as "unstable", probably because there are 6 new warnings (https://build.ros2.org/job/Rpr__common_interfaces__ubuntu_noble_amd64/24/gcc/new/) from the "deprecated-declarations" that are introduced by this PR. @tfoote I guess keeping on using the deprecated encodings is not an option anymore?

[tfoote]

You need to explicitly suppress those warnings that are known to the developer for backwards compatibility.

https://stackoverflow.com/questions/13459602/how-can-i-get-rid-of-deprecated-warnings-in-deprecated-functions-in-gcc

Luckily clang will pick up the GCC ones

https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas

[christianrauch]

I wrapped the code that is still using the deprecated marked encodings inside the GCC diagnostic pragma:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
[...]
#pragma GCC diagnostic pop

[christianrauch]

@tfoote Can you have a look at this again?

[tfoote]

Thanks for taking the time to mark these as deprecated. This will be helpful going forward. The change looks good. Sorry for the high latency, I'm on leave at the moment. I will come back to this for merging when I'm back in the office to avoid disruptions when I can't pay close attention unless someone else gets to it sooner.