Add MAX_MULTI_UPDATES config

[Deconstrained]

Description: If PUT, and json is a list, limit the list size to 250.

Justification: This will prevent the client from making unnecessary HTTP requests that are expected to elicit a status 418 response because the limit is exceeded, or even providing the basis for batching requests to handle a very large list.

Risks: other endpoints could potentially implement multi-update without such a limit, or with a different limit. We may need to use a crutch similar to ENTITY_WRAPPER_CONFIG to get around this in the near future if/when this happens, to avoid arbitrarily depriving users of a higher multi-update limit in an endpoint that allows it.a We then have another manually-maintained list where adding support is a one-liner.

Precedent: we already do this for the max offset in pagination to prevent wasted API calls, so it makes sense to do it here, despite the risk of us adding another antipattern config. Where the assumptions made in the abstractions of this client do not hold universally true for all constituent APIs of REST API v2, is where we have to manually maintain some list that distills each divergence between client expectations and API design (or automate it if possible using the documentation source).

Sources:

• Manage Incidents
• Manage Alerts (it is incorrect at 500 but in the process of being updated as of this writing)

The limit should eventually be documented here: https://developer.pagerduty.com/docs/ZG9jOjExMDI5NTU0-endpoints#put-resources-update-multiple