Allergic to SQIDs

## Is your feature request related to a problem? Please describe.
Element labels make sense to users more than SQIDs do when reading their code. But SQIDs are required for continuity of service as labels can change.

## Describe the solution you'd like
An article giving a demo workflow of how you'd use labels in the first instance to build a data query, but link those through to SQIDs to create a persistent query through different versions of an API data set.

Overarching workflow would be along the lines of:

* Define required labels
* Query data set **v1** meta data to attach relevant SQIDs to each label
* Create data set query for data set v1 using SQIDs from data set **v1**
-------------- Data update --------------
* Use previously defined id labels
* Query data set **v1** meta data to attach relevant SQIDs to each label
* Re-run data set query for data set **latest** using SQIDs from data set **v1**

The idea is that the SQIDs would never be visible in the code throughout this, they'd be stored behind human readable named string or string vector variables, e.g. phase_primary_id, phase_special_id, phase_ids.

## Additional context
This is off the back of user testing with NT in particular, where the new versions being published broke his code because he was using labels rather than ids.