feat(en,de): Add encoding methods for common messages

[jbeyerstedt]

About this PR

Sometimes it can come handy to be able to parse and encode individual messages "manually". Currently you would need to use rasn on the data types by your own, while this library could just add the required methods using some rust macros.

So this PR adds "decode" and "encode" (from/to UPER/ XER/ JER) methods to the ITS messages and their "payload" after the ITS-PDU-Header as well as for the PDU header itself.
I don't think that more data types are usually needed. And if that's the case, there's still the route via "rasn".

I chose to add methods instead of a generic function for ease of use.

To-Do

• Validated that encoding works when using this library
• Validated that decoding works when using this library

[BendixBuchheister]

Couldn't we just make those encode_to_xy / decode_from_xy public and call e.g. decode_from_uper(denm), instead of DENM::decode_from_uper().

pub fn decode_from_uper<D: rasn::Decode>(input: &[u8]) -> Result<D, alloc::string::String> {
    rasn::Codec::Uper
        .decode_from_binary(input)
        .map_err(crate::map_err_to_string)
}

Then the user can call this for any asn1 type, without the need to directly implement the macro for each type.

Or maybe make EncodingRules::codec() public, then you should be able to call rasn's encode_to_binary() / decode_from_binary() (not sure if there is any issue, since the rasn module isn't re-exported).

[jbeyerstedt]

Couldn't we just make those encode_to_xy / decode_from_xy public and call e.g. decode_from_uper(denm), instead of DENM::decode_from_uper().

I already thought about this and see the advantage of having a generic function. But I still think it's the nicer "interface" to have a method than some generics because you can call them from the instance (or type). Which also means that this "capability" shows up in the docs of the type and you don't need to remember that some other functions also exist which you can use with them.

But see #73 for the alternate solution.

[BendixBuchheister]

Yeah, it's true that it is easier to remember / use the interface when you can call these functions on the instance/type.

But since it would be really nice to be able to decode any type not just a hand selected subset, we might just go forward with both approaches, or what would you say?

[jbeyerstedt]

we might just go forward with both approaches, or what would you say?

Just pushed a combination of the two PRs here. The macro uses the "stand-alone" function to prevent code-duplication and has a note that the methods at the class/ instance are just for ease of use.

[BendixBuchheister]

LGTM