Implement a config resolver

[carlpett]

As discussed in #208 and on gitter: This PR implements a method for populating flags from an user-defined external source, such as a config file. Some properties:

• This source has lower priority than flags set on the command-line, and envars.
• Multiple resolvers can be added, and they will be used in the order added, until the first match is found.
• The lookup is performed using the name of the flag, unless the user sets a custom one.
• It is possible to disable usage of the resolvers on a per-flag basis.

Things I'm not sure about and would appreciate some discussion around:

• Currently it is not possible to add a resolver directly on a flag. I don't see that this would be useful, but it wouldn't be hard to add if there is a use-case?
• I did not check in any implementations for users, but possibly it would be useful to ship some standard ones such as yaml/json file sources? Probably in a separate package in that case?
• Errors must be handled in the Resolve method. I'm not sure how an error would best be handled if propagated back up the stack? But I guess someone will implement a remote call resolver, which could lead to all sorts of interesting errors, so maybe it would be better to have it after all...

(Also, naming, of course)

[alecthomas]

Currently it is not possible to add a resolver directly on a flag. I don't see that this would be useful, but it wouldn't be hard to add if there is a use-case?

I don't think that's necessary.

I did not check in any implementations for users, but possibly it would be useful to ship some standard ones such as yaml/json file sources? Probably in a separate package in that case?

A JSON one would be fine, as it's in the stdlib, but I don't think a YAML one is necessary.

Errors must be handled in the Resolve method. I'm not sure how an error would best be handled if propagated back up the stack? But I guess someone will implement a remote call resolver, which could lead to all sorts of interesting errors, so maybe it would be better to have it after all...

Yes, errors should be handled.

I'm going to merge this, then make a couple of changes (rather than harassing you with even more comments :)). I'll implement the error handling when I do that.

Thanks again for taking the time to implement this!

[daixiang0]

@alecthomas @carlpett hi, i do not find docs about this, is that missed?

[daixiang0]

@alecthomas @carlpett @Joseph-Irving any update?

[carlpett]

@daixiang0 As far as I know, this is still only implemented on the v3 branch, so that would be why it is not documented on the v2/master branch.