Add metadata field to Gopkg.toml; warn on unknown fields

[sdboyer]

As part of #276, we want to be able to provide a bit of future-proofing against the likelihood that we're going to need to add more properties to the data in Gopkg.toml and Gopkg.lock (e.g. for #291).

To that end, we should take (yet another) note from Cargo, and

1. Introduce a [project.metadata] field in Gopkg.toml, which should be ignored by the parser except to enforce that it's a map type.
2. Warn if we encounter any unknown fields in Gopkg.toml. This should help discourage unintentional use, and channel anything that users want to add into that metadata.

This may be a bit awkward, given that we don't have a project field to start with. I'm going with that, though, because I think it's likely we'll end up adding one. However, if that's too much of a pain, I'd also be good with just having a [metadata] top-level field.

[bestform]

What would be part of [project] and why is it likely to be added? I would prefer the top-level [metadata] field but I see the point to use project, as it would be awkward to have metadata outside of project as soon as it is introduced.

So it boils down to the probability of a project field.

And consider: if we chose [project.metadata] now, we lose the option to chose an alternative name for [project] later.

[sdboyer]

Thanks for feedback!

What would be part of [project] and why is it likely to be added?

The most immediate, functional need would be if we want to have Gopkg.toml indicate the root of the project. The reasons why that might be a good idea are pretty involved, so let's not delve into that, and just leave it at that there's a nonzero chance of wanting it.

Other members would include non-functional information common in other systems - names of authors, license, etc. Again, idk if we end up with that stuff, but there it is.

we lose the option to chose an alternative name for [project] later.

I'm not too worried about this one - I think project is pretty much settled terminology at this point, and Russ has indicated he's 👌 with it.

So it boils down to the probability of a project field.

i think mostly, yes. Though there's a possibility (let's really hope not) version the format of the file itself. If we do that, then we'd probably want a different section for that information, to clearly delineate it from information that describes the project, as opposed to the file.

I'm increasingly inclined towards using it because it seems like the safer, more future-proof thing to do.