feature: RawContent field type

[immesys]

Is your feature request related to a problem? Please describe. A common pattern I have in my application is needing to compute the hash of the encoding of a struct field (for verifying a signature). It's annoying to use RawMessage because I do want the struct deserialized, and it's often fairly recursive, so there's a lot of boring added code to manually unmarshal the RawMessages manually for multiple layers.

Describe the solution you'd like Go's ASN1 library has a neat solution for this: if the struct's first field is of type asn1.RawContent, then the bytes that are deserialized for the rest of the struct are present there in raw form. But it does not prevent the rest of the struct from being decoded, so you get the best of both worlds.

Describe alternatives you've considered Other than the RawMessages approach, I considered a solution using a known name of field (like how the _ field is special) but I figured the odds of accidentally picking a name that people legitimately use is high. Thus the approach of introducing a new type and letting the user use any field name is safer.

Additional context Here's an example of where this pattern occurs. I admit it looks contrived, but there are hundreds of occurrences of the asn1.RawContent being used this way on github, and CBOR targets similar use cases.

type Message struct {
	ToBeSigned struct {
		Raw cbor.RawContent // Allows for the outer signature to be verified
		Sender string
		Recipient string
		AEADEncryptedPayload []byte
		AdditionalAuthenticatedData struct {
			Raw cbor.RawContent // Allows this struct to be checked as part of the AEAD easily
			Foo string // But it's also handily unpacked automatically
			Bar string
		}
	}
	Signature []byte
}

I'm willing to do the work to implement this and submit a PR, if it's something you think you'd want.

NOTE: I'm new to this code base, and CBOR, so if there is already a better way, please let me know :-)

[fxamacker]

@immesys Thanks for suggesting this feature, I think it's a useful feature to add. :+1:

I can implement this feature if you'd like, or you can open a PR if you're OK with the contributing guideline and pull request template. Anonymous code contributions are not accepted, so contributors would need to use their real name, etc.