Scoping changes to the Message Participants page

@okaycj is already working on this.

Since Feb 19, 2025.

## Summary

We're considering making some changes to the Message Participants page, in hopes of helping researchers with pain points related to keeping track of participants (e.g. who's been paid, who has actually completed the study, etc.).

## Proposed changes

1. **Reorganize the page to make better use of the space**
- Purpose: Currently the "Previous Messages" table takes up a lot of space, and there isn't much space left for writing a new message. We could consider making these two boxes equal in size. We could reduce the width of the "Previous Messages" table by e.g. using a shorter date format for the Date column, removing/trimming the UUID in the Recipients column. Another option is to put the "Previous Messages" table below the box for writing new messages.
2. **Clarify the box for writing new messages**
- Purpose: I think researchers often miss/ignore the "recipients filter" box and then get confused about why a given participant's name is disabled in the "Recipients" option. We've made some improvements to the docs on this, but this page could also be clearer. Suggestions:
- Rename the box label to something like "Write new message"
- Inside this box, re-name the section called "Please Select Recipients Filter" to something like "Select Message Type", with some help text underneath, e.g. "The message type determines which families you can contact, based on their individual email preferences".
- For each message type option, give a clear short label along with the description, e.g. "New Session", below: "Message participants about another session of this study".
3. **Allow form parameters to be passed on page load**
- Purpose: If we include a "Message this participant" button on the Individual Responses page (see #1497) then it would help to be able to send researchers to page with (1) the Recipient field already filled in with the relevant family in the new message box, and (2) the "Previous Messages" table already filtered to show just the messages sent to that participant.

## Mock ups


## Implementation notes and estimates

- **Reorganizing the page layout and adding/changing labels and text**. This should be straightforward. It will require layout changes in the template.
- **Allowing form parameters to be passed on page load.** In some of our other views (e.g. the Study List view / Manage Studies page), the URL query parameters are processed by the view and are used to provide the context data. With this approach, the Message Participants page would only have access to the _filtered_ set of previous messages, which means that we'd need to trigger another GET request if the user wanted to access previous messages outside of that set. So rather than processing the query parameters through the view, it might make more sense to keep the page load the same (i.e. the page receives all previous message data) and do any table filtering etc. via JavaScript and DataTables. We could also automatically fill in the "Recipients" field by grabbing it from the URL query parameter and adding it via JavaScript.