Allow customization of the 'response'/'child' query param names

Summary

By default, we pass the response/child IDs as "response" and "child" in the URL query parameters for (1) external study links, and (2) exit URLs. We should keep this as the default but give researchers the option to change it to whatever they want.

Description

The fact that we don't allow customization of these parameter names is a problem because some sites and booking platforms enforce specific names or naming conventions for inbound query parameters. One example is youcanbookme (see the corresponding issue), which requires that parameter names be in all caps. Another is Google Forms, which allows you to pre-fill question responses using query parameters, but you have to use the parameter names that they provide (e.g. entry.264543955). Giving users the option to customize the response/child query parameter names would solve both of these problems.

Implementation

This would need to be another field or two on the study table, so it requires a DB migration. The field could be a dict with one or both mappings for custom name values (e.g. { response: "entry.264543955", child: "CHILD" } ). The default could be NULL/None (which means use the existing names), or it could be a dict that maps to the current/default values: { response: "response", child: "child" }. This field in the study edit/create form would not be part of the "monitored" group, which means that researchers can change these values during data collection without need re-approval.

We will also need to add the following tests for both external studies (study URL) and internal studies (exit URL):

• Default parameter values at study creation
• Custom parameter values at study creation: each one separately, and both
• Changing the parameter values during study edit: custom to default and vice versa
• Editing parameter values does not change study state (approved -> rejection)
• Different character combinations that should be ok to use (alphanumeric characters etc.)
• Handling/preventing malformed field values (e.g. not a dict, incorrect keys, non-string values, invalid characters)

Start by tracing study creation and editing, the study table, and the code that builds external study links and internal exit URLs. Review existing tests for both URL types before adding coverage for defaults, custom mappings, edits, approval state, valid names, and malformed values. Done means researchers can change either parameter name without changing the default behavior or study approval state.