RFC: decentralized validations

### Background

ember-validations and ember-cp-validations are fundamentally _centralized_, with a single form or backing model declaring all validation rules. Key benefits of centralized validations include
- it's easy to write validations that involve multiple fields
- if done at the model layer, they do not need to be replicated for each view of the model
- if done at the model layer, keeps validations near other business logic

HTML's built-in validation (which admittedly is not widely used, I think primarily because it's hard to style) is fundamentally _decentralized_. Each field declares its own validation rules and can intercept and block the form submission. Key benefits of decentralized validations include
- a complex form element can apply validations wherever it is used
- it's easy to change validation rules to fit different use-cases; in a centralized world, this requires duplicating the ruleset, then adding/removing/modifying as needed

I'm particularly interested in that first benefit of decentralized validations. I have a few scenarios in my app where an individual _field_ knows more about its validation rules than the surrounding _form_ or backing _model_. I'd like a way for the field to look up the "closest thing with validations" and add one to it when it is instantiated, then remove it when it is destroyed.
### Use Case: sudo

Some forms require entering into "sudo mode," which involves re-entering your password. This is exchanged for a token that is valid for a few minutes, after which sudo mode expires.

One way to model this in the UI is to have a two-step (wizard-style) form:
1. if not in sudo mode, enter password
2. the rest of the form

Many people find that extra step a burden, so we would prefer to have a single form. One of the fields would be a `{{sudo-field}}`, which has two states:
1. if not in sudo mode, a password field
2. if in sudo mode, display that the user is in sudo mode and don't require a password

The difficulty, though, is that the `{{sudo-field}}` needs to make a request to exchange the password for a token before the form submission can continue. There are several ways to do this, but I think the most elegant is to treat it as an async validation.
### Use Case: dangerous field

I have a "user settings" form that has a grab-bag of options, none of which have any relation to one another; they're simply all attached to the same model. Most of those fields are "normal," but a few of them are "dangerous." If a user changes the value of one of those fields, we want to interrupt the save to have them confirm it.

I'd rather have the individual fields know whether they are dangerous than have the user know the set of dangerous fields. A good way to model that would be to have the fields add an async validation to their parent form.
### Implementation Ideas

One approach might be something like

``` hbs
{{#validated-form action=(action 'save') as |validations|}}
{{sudo-field validations=validations}}

{{regular-field}}

{{dangerous-field validations=validations}}
{{/validated-form}}
```

Then `{{sudo-field}}` and `{{dangerous-field}}` would do something like

``` js
validations: undefined,

registerValidation: Ember.on('didInsertElement', function() {
this._validation = this.get('validations').add(buildAValidation());
}),

unregisterValidation: Ember.on('willDestroyElement', function() {
this.get('validations').remove(this._validation);
})
```

It's a little unwieldy, though.
### Parting Thoughts

Perhaps this is so big it deserves to be its own addon. I'm totally fine with that. If so, it would be good to iron out the API over which that addon could talk to ember-cp-validations.

I wrote about this [previously](https://gist.github.com/jamesarosen/a7d6299caec9f05befb93dd53a759b86). I didn't get any responses there, though, so I'm not sure how helpful that post is.