Providing first class support for user-specified dataclasses.field instances

[rsokl]

There is a sizeable demand for Hydra to support custom help messages through the CLI: https://github.com/facebookresearch/hydra/issues/633

It appears that the leading candidate for supporting this, at least for structured configs, is via dataclasses.field(..., metadata=<...>): https://github.com/facebookresearch/hydra/issues/633#issuecomment-636540767 and https://github.com/omry/omegaconf/issues/131#issuecomment-955641379.

Presently, we provide limited (and primarily undocumented) support for users to directly pass field objects to builds and make_config and do not make any assurances that we preserve any of the associated metadata. It also appears that we do not perform any value-validation on fields.

Thus I plan for us to:

• Provide explicit support for passing field instances directly to our config-creation functions
  • ensuring metadata is preserved
  • ensuring parity with all validation that we perform
  • adding test cases that explicitly exercise fields-as-config-values

An edge case that I anticipate is that we might not permit fields as positional arguments.

Additionally ZenField should expose a metadata field. Ultimately ZenField is the same as dataclasses.field, except it can specify name and type as well; so perhaps we should expose all of the field options here, other than default_factory, which we handle automatically.

Lastly, if OmegaConf/Hydra does end up going this metadata route for supporting help messages, then we could potentially add a new feature to builds, where we can parse different styles of docstrings and auto-populate docs fields in metadata. This way, users need not duplicate any docs - the help messages will be derived directly from the source documentation!