Provide API abstractions for library types.

[rsmmr]

More complex unit types often end up containing some internal fields or variables that will remain uninteresting to the user of the type (e.g., protocol fields without much meaning, but also internal state like temporaries computed dynamically). For "normal" protocol parsing that's not much of an issue, but it can become challenging for unit types that provide building blocks for other Spicy code to use (e.g., ASN.1 data types in an ASN.1 library module for others to import). To use these, the upper-layer code needs to know what the relevant information is that it can (and should) access, and what's better to ignore. Right now, the only mechanism we have to hide fields is to leave them anonymous, but usually not helping much here. It would be great if we had a way to specify an API for unit types, looking for thoughts there.

[rsmmr]

One idea would be adding private fields and variables:

type X = unit  {
    ...
    private x: int32:
    private var tmp: bytes;
    ...
};

Private members would be accessible only from inside the unit itself, but not from external users.

[rsmmr]

Also, supporting unit methods could help hide implementation details:

type X = unit  {
    ...
    method asBytes() : bytes { return self.tmp; } # Access normalized content
    ...
    private var normalized_data: bytes;
    ...
};