Bump MAVLink version

[tbolin]

Bump the MAVLink version to the latest as of 2026-01-16.

Also adds support for the "superseded" tag , which is required for the new message definitions.

[pv42]

There seem to be new dialects added with this change. They should be properly integrated (feature gate defined in cargo.toml and doc for there existence in the lib.rs top comment).

[onur-ozkan]

There seem to be new dialects added with this change. They should be properly integrated (feature gate defined in cargo.toml and doc for there existence in the lib.rs top comment).

Good catch. I just created this issue regarding to same problem.

[tbolin]

I have added feature gates and documentation for the new dialects. However, cargo test --features arbitrary,standard fails.
I think the problem is that common defines but does not actually use the MavBool enum, so the parser defines it as a normal enum and not with bitflags, and then

    pub fn as_bool(&self) -> bool {
        self.contains(Self::MAV_BOOL_TRUE)
    }

is invalid, since self.contains doesn't exist.

[tbolin]

cargo test --features arbitrary,standard should compile and pass now.
I changed self.contains(Self::MAV_BOOL_TRUE) to *self == Self::MAV_BOOL_TRUE

[onur-ozkan]

This is not right as self implements bitflags.

[tbolin]

I need some input on how to solve this.
The problem is that self does not implement bitflags if the dialect defines MAV_BOOL but does not use it in any messages (e.g. the standard dialect).

I think the best solution would be to default to either u8 or i8 if the type of MAV_BOOL can't be deduced from how it is used in the dialect. Then MAV_BOOL would always implement bitflags and self.contains(Self::MAV_BOOL_TRUE) would always be valid.

The only way I could see that this could cause problems is if a dialect that currently defines but not use MAV_BOOL starts using MAV_BOOL in a way that does not agree with the default.
However, I'm not sure if the current solution (not implementing bitflags at all) would be any better in that case.

I'm also open to other suggestions.