Requests over ng's form and multipart limits get a 500, not a 4xx #102

A request over one of ng's limits gets a 500 instead of a 4xx status.

The request parsing added under #66 enforces limits by throwing IllegalArgumentException:

• NGStandardRequest.MAX_FORM_FIELDS (1000) and MAX_FORM_CONTENT_LENGTH (200,000 bytes) for form-encoded bodies and query strings;
• NGMultipartRequest.Limits, set by the ng.multipart.* properties (maxParts, maxContentLength, maxMemoryPartLength), for collected multipart requests.

Dispatch turns any exception into the exception page, a 500. That's wrong for the client and noisy for the operator: it logs a stack trace for what is the client's error.

What's needed is a way for an exception to carry the status it should produce, for example an exception type with a status (NGHTTPStatusException( 413, "..." ) or similar) that dispatch maps to a plain response instead of the exception page:

• 413 for content over a length limit;
• 400 for too many fields or parts, or malformed content.

The same mechanism would serve other client errors that currently surface as 500s, such as the duplicate form value check in formValueForKey.

Jetty behaved the same before: its limits were exceptions inside the adaptor, which also became 500s.