The test case was erroneously comparing whole submsg structures,
which could result in false errors when padding bytes differed.

Thought I was cleaning up the naming by calling the function const_cast(),
because that's what it does. But of course it conflicts with the C++ builtin,
so renaming it to pb_const_cast() now.

Fix infinite loop in pb_check_proto3_default_value

- Occurs with proto3, PB_FIELD_16BIT and submessage > 255 bytes
- Add test case for PB_FIELD_16BIT and proto3

Adds support for proto3 and POINTER field types to have
fixed length bytes arrays. Also changed the .proto option
to a separate fixed_length:true, while also supporting the old FT_INLINE
option.

Restructured the generator and decoder logic to threat the inline
bytes fields more like "just another field type".

Max_size is the allocated size, so users had to add +1 for
the null terminator. Max_length does the +1 automatically
in the generator.

Fix documentation for protoc --plugin argument

WIP: cmake cleanup to support installable host tooling

cmake: Fix library name

Signed-off-by: William A. Kennington III <wak@google.com>

The produced static library should be `libprotobuf-nanopb.a`
instead of the current `liblibprotobuf-nanopb.a`.

Signed-off-by: William A. Kennington III <wak@google.com>

Fix closing a non-empty substream resulting in an incorrect stream state

Previously the field iterator logic didn't know whether two
oneof fields were part of the same union, or separate. This
caused wrong pointers to be calculated if multiple oneofs were
inside a single message.

This commit fixes this by using dataoffset of PB_SIZE_MAX to
indicate union fields after the first field.

Theoretically PB_SIZE_MAX is also a valid value for data offset,
which could cause errors. Adding a compile-time assert for this
is somewhat difficult. However I consider it extremely unlikely
that there is any platform that could trigger this situation, as
it would require 255 bytes of extra data/padding between two protobuf
oneof fields. On 64-bit architectures the worst case is 16 bytes,
and even esoteric platforms only align to 64 bytes or so. Manual
modification of the generated .pb.h file could trigger this, but
even then it would require pretty bad luck to happen.

Make pb_decode_varint32 public API