Engine: expand concept of "validation"?

Currently, we use "validation" as a generalization of two ODK XForms spec concepts:

- `required`: if a form specifies that a field is required, we check that its value is non-blank; failing this check is a "violation"
- `constraint`: if a form specifies a constraint expression for a field, we check that the value satisfies it; failing this check is also a "violation"

These are mutually exclusive checks: `constraint` is only applied for non-blank values. We've reflected this in the engine's validation APIs, where a given node will have 0–1 "violations".

But "validation" has a broader colloquial meaning, which would be convenient to apply to other aspects of engine behavior. This potentially ties into how we represent error conditions _and it may allow us to relax some of them_.

Some examples (not exhaustive):

- We currently `throw` when some values are incompatible with a particular ``/`ValueType`
- As of #288, we `throw` when attempting to assign an incomplete subset of available `` values
- [TODO: I'm almost certain there are other examples, they just escape me at time of writing]

This creates some weird inconsistencies in the engine API, and potentially in UX too. In many cases, setting an invalid value is _allowed and validated without blocking until submission_. In other cases, it's disallowed. This also poses some challenges in client integration, because it's inconsistent where and how we surface errors. That will become _less_ risky when we adopt `Result` types for producing errors, but can still cause unnecessary problems and add unnecessary complexity.

The main challenge (to my mind) is that the current design for validation violations being _mutually exclusive_ is incompatible with an expanded colloquial concept of validation. We could address that by introducing _yet another_ bag of (client reactive) state, but that has its own problems too.

Not making any recommendations on a solution yet. I just wanted to capture some common themes and context while it's on my mind!

Start by reading the issue's discussion of validation APIs, violations, ValueType incompatibilities, and incomplete assignments. Audit the engine behavior described there and identify the validation and error cases that would need a consistent design; the issue does not define a finished scope or acceptance criteria.

Written by the indexing model from the issue text.