Clarify and generalize `Signal` semantics

The semantics and schema of the `Signal` table in [models/reference.py](https://github.com/IRFM/event-storage/blob/main/event_storage/models/reference.py) could be clarified and generalized slightly to adapt better to different machines/projects with different conventions:

1. The name of the field `"diagnostic"` does not naturally cover machine/plant instrumentation (e.g., thermocouples, strain gauges, accelerometers installed on structures), as I believe it is more commonly used for "plasma" diagnostics. Both are maybe better described as `"instrumentation"`, which seems like a cleaner umbrella term. Maybe that field could be renamed to `"instrumentation"` to avoid any ambiguity and cover machine/plant instrumentation as well?

2. The `"type"` field is currently free text. This makes the data flexible, but it also allows drift in spelling and conventions. For example, the same concept might be entered as `"IR Video"`, `"IR video"`, `"ir_video"`, `"IR"`, etc. This becomes a practical issue if filtering or aggregating events by signal type is needed. A dedicated `SignalType` reference table (with a foreign key in `Signal`) would provide controlled vocabulary and much more reliable filtering.

3. The `"path"` field seems adapted to hold a filesystem path, which might not always be adapted depending on the infrastructure. Depending on the machine/project, some data may come from external databases, remote APIs, archived systems, or other backends where a filesystem path is not the natural identifier. I think this could be split into two fields:
- A more general, unique signal identifier like `"reference"` or `"tag"` that is independent from the logic used to retrieve it (i.e. local path, remote server, etc.).
- (Optionally) another field like `"path"`, `"source"`, `"location"`, etc. to describe where the data can be retrieved from, when relevant.