Improve validation for non-interactive consumption

Please improve validation to support consumption by code.

This would in my opinion
* allow supporting error codes or error tokens instead of just strings meant for human interpretation to communicate the type of error,
* allow custom formatting of the resulting errors,
* maintain and make available validation metadata (e.g. min/max, list of valid values or reference to a resource that allows obtaining them, etc)
* make available the offending (property) values
* would make it possible to build property paths of properties that offended validation and to parse them and use them in meaningful ways at the consumer end,
* make it easier to replace the default infrastructure with something else, short of not using model binding or writing validation without using the built in support for it

Today, the validation infrastructure that is for example used with model binding is based around string messages. Essentially, the [ModelError class](https://docs.microsoft.com/en-us/aspnet/core/api/microsoft.aspnetcore.mvc.modelbinding.modelerror) carries the error information and in the case where the model comes from a validation attribute, only the `ErrorMessage` property is set and it might contain a resource string in any language. This means that validation results aren't suitable for consumption other than to be presented as-is interactively.

One case for this is Web API where the consumer is not a website or an app, but another service. And even if the consumer is a website or app and the errors are for interactive use, the client may still be able to handle or prevent a number of issues based on the codes or tokens and other metadata. Improving this story may also make client side validation easier, especially where it isn't being done by existing JavaScript.

A very good case can also be made for services that are used by different consumers. The consumer can be made to decide what language is used by adding its own or overriding the service provided error messages, using the succinct type of error and any metadata and property values that might be carried.

It also simplifies writing tests.

#6549