add support for const length arrays ([u8; N])

[ryankurte]

minimal addition to implement prost::encode::BytesAdapter over [u8; N] (alongside Vec<u8> and Bytes<u8>.

• refactors BytesAdapter to be externally implementable (should make add encoding support for heapless::{Vec<u8>,String} #730 and other external bytes types possible)
• adds BytesAdapter impl for [u8; N] (note this only works with N<=32 due to Use const generics for array Default impl rust-lang/rust#61415, could mitigate this by exposing Newable workaround)
• propagates errors from BytesAdapter in case of a length mismatch for const types

[VladimirBramstedt]

the problem is that there is no way to express that in protobuf.
if you have [u8;20] and the field you are parsing only contains 10 bytes? what do you do? you'd need to add some parameter (len) to track how much of that buffer is filled, etc... at which point you want heapless::Vec<T;N> (which does also implement Default), which the maintainers did not want to add...

[ryankurte]

the problem is that there is no way to express that in protobuf.

if you have [u8;20] and the field you are parsing only contains 10 bytes? what do you do?

it seems pretty reasonable to me to encode a fixed length field as variable length in the proto, and to fail on the decoding of a mismatched length, as one would with any other invalid or unmatched message / field (though this PR does not yet have that behaviour).

at which point you want heapless::Vec<T;N>

this addresses an issue with prost::Message not functioning over otherwise readily serializable type with explicitly sized fields, i specifically do not want to replace these with variable length versions that don't make sense from the application side. whether or not this is the ideal construction of application and serialisation objects, it is a problem that exists for users of core language primitives.

[VladimirBramstedt]

it seems pretty reasonable to me to encode a fixed length field as variable length in the proto, and to fail on the decoding of a mismatched length, as one would with any other invalid or unmatched message / field (though this PR does not yet have that behaviour).

Alright, but that behaviour is the key point, in my opinion.
you are not merely adding the ability to use arrays as byte containers, you are also stating here that decoding would fail if the size doesnt match. without that assertion this PR makes no sense, and that assertion isnt in the PR as is. is this a draft PR then?

[ryankurte]

updated PR to propagate errors, expose BytesAdapter. it'd be great to know if there was any interest in merging something like this prior to spending more effort on it?