540 standardize metadata

[daniel-slaugh]

Resolves #540

A couple judgement calls specifically to review:

1. hydroserverpy had some functions that needed their required positional arguments updated since the meaning of name and code was changed for ProcessingLevels and ResultQualifiers. Mostly, this won't break code, but here are some examples of before and after. The new rule is methods take name and description by position or by name, but optional parameters are by name only.

# Before: create(code, description=None, workspace=None, uid=None)
# After:  create(name, description, *, code=None, workspace=None, uid=None)
hs_api.resultqualifiers.create("ICE", "Ice affected")        # still correct, now name + description
hs_api.resultqualifiers.create("ICE")                                 # TypeError: missing 'description'
hs_api.resultqualifiers.create(code="ICE", description="…")  # TypeError: missing 'name'

# Before: create(code, name, description)
# After:  create(name, description, code=None)
hs_api.processinglevels.create("0", "Raw", "Unprocessed data") # TypeError: takes 3 positional arguments but 4 were given
hs_api.processinglevels.create("Raw", "Unprocessed data", code="0") # OK

2. migrations fail loudly rather than truncating: if any ObservedProperty.code, type, or definition exceeds the new limits, the migration stops and names the field. I don't think this should be a problem since the new limits are pretty generous.
3. Definitions are now validated to be URLs, but for the migration, I'm not requiring existing free-text values to be updated. This will make the migration go through, but future edits to those tables will fail validation.
4. There are three migrations 0017-0019. This can be squashed, but you mentioned earlier you wanted to clean up the migrations before releasing 2.0, so I'm thinking I'll just leave it as is and squashing can all be done together.