`form` objects, replacing `usability` and opening up input profiling

[stuartpb]

Per the model clarity espoused in #150 and laying the groundwork for #126, I think concerns that involve forms should have a form object to describe the parts of the form, which would eat all the parts of the schema now that currently touch stuff like this, such as *.usability.

Some thoughts:

• Objects under a form would represent an input each, more or less (ie. there might be objects that describe another aspect of the form that isn't part of any input), with the property names being what inputs are.
• Maybe confirmation inputs should be under a repeat object and otherwise mirroring the higher-level input (like password and repeat.password). If there's no "repeat" for an input, that can be documented by giving a value of "none" (to explicitly profile that the input is missing) instead of an object describing an input. (I think this might be the first instance of a polymorphic property in the current schema, but, honestly, I'm fine with that.)
  • This means that you might have registration.form.repeat.email = 'none' as the only form property, which is weird, but I guess I'm okay with that. The hard part I'm wrestling with is what to do when you don't want to profile anything about an input other than the fact that it exists: {} feels grody, but it might have to do. (Though whatever the optional / required enum is will probably be simple enough.)
• The other thing that's currently a usability thing is visibility. I'm thinking this enum:
  • hidden: Always hidden.
  • visible: Always visible.
  • showable: Hidden by default, can be toggled on.
  • hideable: Visible by default, can be toggled off.
  • holdon: Hidden, can be shown by holding a button (hides again on release). (This kind of detail might not be worth documenting beyond showable.)
  • The toggle enums imply that it can be toggled back, of course. If it can't, then something weird is going on, and it's worth conveying via caveat notes.
• To document if a field is required or not, I'm thinking a requirement enum with values of optional and mandatory? Bikeshedding: maybe "presence" or something that describes the notion of the input having content filled in. usage?
  • If this could have a third state to represent inputs that aren't present (instead of introducing the first polymorphic property, as now that I think about it I'm not as okay with that as I was a few minutes ago), that'd be ideal. usage: none feels pretty natural.

[stuartpb]

#164 describes why I'm not okay with none being a value of an input instead of a property of an input.

[stuartpb]

Per #168, password.change.form.current.usage: required will also replace password.change.reauth: password.

[stuartpb]

You know what, I think I'll just make usage a mandatory property (since it carries some rather crucial detail), and just call it input, so all three states make natural sense:

• input: optional - it's an optional input / your input is optional.
• input: required - it's a required input / your input is required.
• input: none - there isn't an input / you have no input.

The thing that kinda bugs me is that you could make a similar case for this being the name of visibility (or, really, any property of an input), but I'm willing to live with that.

Also: visibility would make more sense if it were called text (as broad as that name is, again, it's the best fit in this context). Maybe style or characters (I like characters because it lets me open the door to non-character-based hidden values, if that ever catches on, via a different field name, or a new enum state).

[stuartpb]

I'm also introducing login.form.persist.checkbox as an enum between checked and unchecked, which addresses #96 (comment), and ensconces the "inputs have a property that describes what type of input they are" pattern (although it's not super followed - for instance, in the PR I'm drafting now, there's no documentation for password.change.form.newpassword.input, because I can't imagine it having any value other than required).

[stuartpb]

Better than characters or visibility would be masking, which nails exactly what the property describes, and was apparently a term that eluded me when I was writing this up initially. I'm probably going to do one last tweak for this.

[stuartpb]

Also, stating that passwords are masked everywhere when that's so plainly the case 99% of the time, I'm thinking of just yanking that accordingly.

That'll have to be post-schema, though, as a lot of these are just documented because there's no login.form.password.input documentation, so only characters is accepted.