frontend: allow renaming all data-lake variables

### Current behaviour

Variables the user didn't create often have logical names, but they may not accurately reflect what the user wants to do with them, or may be difficult to understand without extra context that cannot be provided.

### Expected or desired behaviour

Options:
1. Implement a renaming mechanism that allows the user to change the display name of any data-lake variable
- Variables should already only be referenced by their IDs, so it should be fine for users to change variable names if they want to
- This should be straightforward to implement in the data-lake table
- This would require extra work to persist across reboots (for non-persistent but recurring variables), and/or to restore a variable to its original name (not sure if that's an important feature)
- Those could be possible by tracking renames and applying them at the start of each session / Profile load, but that may cause some issues, could be quite finicky to implement robustly, and starts to be like option 2
2. Implement a nicknaming mechanism that allows the user to override the display name of any data-lake variable
- We could store a mapping of data-lake variable ID to nickname with the Profile, and reference that as part of displaying a variable
- This should be reasonably straightforward to implement an interface for via the data-lake table (click the name to rename, click a restore button if there's a nickname you want to remove)
- The extra referencing check on every name display lookup may not be ideal, compared to changing the names once and just referencing them directly
3. Implement an alias type of data-lake variable that behaves like the underlying variable for all actions except deletion
- This would allow multiple aliases per variable, but then doesn't allow adjusting names of variables that are already in use (which is likely important)

### Prerequisites

- [x] I have checked to make sure that a similar request has not already been filed or fixed.

Start by locating the frontend data-lake table and the Profile loading and persistence paths. Compare the three proposed approaches, then confirm which naming behavior and persistence rules are wanted before changing anything. Done means the selected design is implemented with a clear way to rename or nickname variables and restore the original display name where required.

Written by the indexing model from the issue text.