deprecate the 'terse' output format; define *_terse output formats in a more generic way

[karenetheridge]

this output, produced by OpenAPI::Modern blowing up during construction when loading a malformed schema:

error parsing schema:
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify/properties/name': got null, not one of object, boolean
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify/properties/name': subschemas 0, 1, 2, 3, 4, 5, 6 are not valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify/properties/name': subschemas 0, 1 are not valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify/properties': not all additional properties are valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify': not all properties are valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify': subschema 1 is not valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties/modify': subschema 0 is not valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema/properties': not all additional properties are valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema': not all properties are valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema': subschema 1 is not valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json/schema': subschema 0 is not valid
'/paths/~1cert~1{id}/put/requestBody/content/application~1json': not all properties are valid
'/paths/~1cert~1{id}/put/requestBody/content': not all additional properties are valid
'/paths/~1cert~1{id}/put/requestBody': not all properties are valid
'/paths/~1cert~1{id}/put/requestBody': subschema is not valid
'/paths/~1cert~1{id}/put': not all properties are valid
'/paths/~1cert~1{id}': not all properties are valid
'/paths': not all properties are valid
'': not all properties are valid

This is the 'data_only' format, as generated by the stringification of a ::Result object.
We could simplify it (e.g. for the user) by only showing errors that are "unique", as determined by eliding errors whose data paths are the substring (bound to the start of the string) of a previous error.

For the example above, all errors would be removed except the first because there is actually only one error and the rest all stem from a contained subschema failing.

For an error coming from an allOf or a oneOf, we would see the errors from all branches, as we should (this should be explicitly tested).

We can call this format "data_only_terse".

This same algorithm can be implemented for "basic" to yield "basic_terse", and allow us to eliminate the existing "terse" structure which has a fair bit of custom (and potentially error-prone) code in ::Result. If I implement this correctly, the existing tests for "terse" can be reused and should yield the same output. (Requests for terse can be redirected to basic_terse with a warning.)

[karenetheridge]

Potentially we should not consider errors elidable if the data_path is the same but the keyword is different. In the above example, the first error comes from the type keyword in the meta/* metaschemas [actually this error was generated 7 times, one from each vocabulary metaschema, but we already deuniquify the entire string of data_path+error], and the second and third errors come from allOf.