Make stored metadata more modular and dynamic

[zaneselvans]

Right now we have a single large metadata library, stored in src/pudl/package_data/meta/datapkg/datapackage.json. This collection of metadata contains a large amount of duplicated information, making it difficult to update and maintain, while keeping it self-consistent, and in line with the current state of the source code. Several potential improvements:

• Fields which show up in multiple resources should only be enumerated once, and inserted into those resources by reference at the time of creation, so that their data types, descriptions, formats, etc. are guaranteed to always match up.
• If we are always going to use the id field as the column that contains autoincrementing primary keys, maybe we should just enumerate a list of which tables have autoincrementing keys, and assume it will be id rather than listing id a dozen times in the autoincrement metadata element.
• Fixed vocabulary fields should all use the enum constraint, and the contents of that constraint should be specified in a single place and inserted by reference, rather than being enumerated in every separate field. Often times these fixed vocabularies correspond to a list or set of dictionary keys in some item in the pudl.constants module right now.
• Top level tabular data resource metadata elements encoding, mediatype, dialect, and format are currently enumerated in every single resource descriptor, but could just be stated in one place and inserted by reference.
• The CC-BY-4.0 license is present in every resource... but could be inserted by reference.
• Many of the resources contain a sources element which is (I think) overwritten by the pudl.load.metadata function. This is confusing.
• Accumulated Depreciation Provision metadata should probably be wiped.
• FERC lines / FERC account metadata should probably be adapted to the new setup (and probably radically reorganized)
• Do we want to keep all the metadata for all of the data sources and all of their individual tables stored in a single file? Or does it make sense to break it out on a per-source or per-resource basis, since the unit of metadata we are generally pulling is a resource at a time, and the name-space we seem to be gravitating toward within the TableSchemas is each individual data source.

[zaneselvans]

Having a single source of truth for the metadata will help when we do things like enrich the TableSchemas (See #426) with additional constraints, units, etc -- once we've added that information in the One True Place, we'll know that it will propagate to everywhere that information appears.

[cmgosnell]

subsumed within #806