Expose the missing required parameter name (header/query/path) in the client-facing 400 APIRuleError, which the gateway already logs internally

PROBLEM
When an API has enforced=true and a parameter is marked required=true, the DataPower API Gateway performs a built-in presence check BEFORE the assembly runs. If a required header/query/path parameter is missing, the gateway raises an APIRuleError and returns a generic HTTP 400:

 {"httpCode":"400","httpMessage":"Bad Request",
  "moreInformation":"One or more required API parameters are missing in the API request."}

The response never says WHICH parameter is missing. But the gateway clearly knows — the exact field name is written to the DataPower transaction log:

 Required API parameter`parameter1` in location header is missing in the API request.

So the information exists inside the gateway; it is simply not surfaced anywhere a client or the API owner can reach it.

WHAT WE ALREADY VERIFIED (all fail to name the field)
1. Built-in 400 response  -> fixed generic message, no field name.
2. API assembly catch (BadRequestError / default) -> cannot catch it; the error is raised pre-assembly ("Cannot find the assembly error rule for 'APIRuleError'").
3. Catalog-level Global Error Policy catching APIRuleError -> the catch fires, but error.message is still generic; dumping error name/status/operation contains no field name.
4. assembly-debug capture trace -> only here is the field name available, inside defaultLog. This is a diagnostic artifact, not client-facing.

The only way to actually name the field today is to change the API contract (move the field into the body and use validate-against: body-param, or drop the header's required flag and re-implement the check in the assembly). Both distort the OpenAPI contract for what should be a built-in behaviour.

PROPOSED SOLUTION
Surface the missing-parameter name that the gateway already computes into a client-reachable context. Any one of the following would solve it:
 (a) Include the field name and its location (header/query/path) in the APIRuleError error context, so an assembly catch or a Global Error Policy can read it (e.g. error.parameterName / error.parameterLocation) and decide whether to return it.
 (b) Optionally include the field name in the built-in 400 response body, gated by a catalog/API property so existing behaviour is unchanged by default.

Making it opt-in / catch-readable keeps it safe: security-conscious teams keep the generic message, while teams that want a better developer experience can echo the exact field.

WHO BENEFITS
- API providers who must return actionable 400 errors to their API consumers (a common banking/enterprise integration requirement).
- Anyone building a Global Error Policy for consistent error formatting — today they can standardise the shape but cannot fill in the missing field name.