Support custom struct tags

[very-amused]

Closes #313

This PR adds support for reading MessagePack field names from a custom struct tag via the //msgp:tag {tagname} directive. If the custom tag isn't present for a field, msg and msgpack are checked next.

Example:

//go:generate msgp
//msgp:tag json

// Heartbeat - A heartbeat message
type Heartbeat struct {
	Service string `json:"service"` // "service" is used for both json and msgp
	Message string `json:"message"`
}

[klauspost]

For better compatibility and consistency could we make it only operate on explicit types?

Syntax could be //msgp:tag {tagname} Type1 Type2 Type3.

Please add tests.

[very-amused]

I've implemented an explicit type-scope directive form (using the suggested syntax) in addition to the file-scope form. When a type-scope directive is used to set a custom tag for a type, any tag set via a file-scope directive be ignored for all of that type's fields. This behavior allows type-scope directives to be used for compatibility while still being able to support the simpler file-scope directives.

Tests have been added for both file-scope and type-scope tag directives.

[very-amused]

@klauspost Could I please get a review of these changes at your convenience?

[klauspost]

I am not a fan of the global directive, but I guess now we give people the option to avoid a potential foot-gun.

Unless there are any objections I will merge shortly.

[philhofer]

I hate to bike-shed but IMO the change was less invasive as purely a "global" setting. With this change at the type level we've got the implementation details bleeding through down to the AST parsing code.

(Keep in mind nothing is truly "global" here -- this is a file-based codegen tool. I can't really envision a circumstance where splitting types between files when the tagging requirements are different would be problematic.)

[klauspost]

@philhofer Are you thinking from an implementation perspective or from a user perspective?

[philhofer]

From an implementation perspective, it's easier to keep directives at the file level rather than the type level, just because of how the code is currently written. You can just stick the desired tag name(s) in parse.FileSet and be done with it.

From a user perspective, I can sort of see why per-type tagging might be useful, but generally you're going to want to use one tag everywhere. In the rare cases where you wouldn't want to do that, you'd probably already have the types in separate files already, where it's a moot point. The tool is already file-based. (And it sounds like @very-amused 's use-case would want this to be applied globally anyway.)

[very-amused]

If it would be preferred to merge with file-scope syntax only, I could use git revert to add commits rolling my branch back to 4f514b9. Just let me know what's best.

[klauspost]

@very-amused Feel free to revert, but keep the test for the global type.

[very-amused]

@klauspost The revert is done, file-scope syntax and associated tests were kept.

[klauspost]

Thanks for the contribution!