is Parameter too complex ?

Maybe I am not clever enough 😭, but the class Parameter is maybe too complex?

The fact that writing docs (I mean valid python documentation) for the constructor is nearly impossible, made me think that we may want to make Parameter to behave differently.

This is a part of the api that the users will want to use if they have anything complex.
## Example:

How can one tell what is required for a parameter that returns an array (the hardware parameter that was discussed in Delft) ?
- looking at the docstring does not give much help IMHO (see below)
- looking at the code kind of hints at what one needs
- trying until it works seems like the only solution if one does not really know the internals

The question is then, do we want to:
1. keep complex base classe and rely on long and detailed manually written documentation
- 👎
- documentation is boring to write and mostly to read
- manuals/examples gets stale very fast
- testing and refactoring is generally more painful
- 👍
- no need to write more code
- no breaking changes
2. Reduce complexity, possibly making things slight less modular
- 👎
- breaking changes
- requires major re write
- 👍
- things are easier to understand and maintain
- sane auto documentation is possible

```
A settable Parameter has a .set method, and supports only a single value
at a time (see below)

A gettable Parameter has a .get method, which may return:

1. a single value
2. a sequence of values with different names (for example,
raw and interpreted, I and Q, several fit parameters...)
3. an array of values all with the same name, but at different
setpoints (for example, a time trace or fourier transform that
was acquired in the hardware and all sent to the computer at once)
4. 2 & 3 together: a sequence of arrays. All arrays should be the same
shape.
5. a sequence of differently shaped items

Because .set only supports a single value, if a Parameter is both
gettable AND settable, .get should return a single value too (case 1)
Args:
name: (1&3) the local name of this parameter, should be a valid
identifier, ie no spaces or special characters

names: (2,4,5) a tuple of names

label: (1&3) string to use as an axis label for this parameter
defaults to name

labels: (2,4,5) a tuple of labels

units: (1&3) string that indicates units of parameter for use in axis
label and snapshot

shape: (3&4) a tuple of integers for the shape of array returned by
.get().

shapes: (5) a tuple of tuples, each one as in `shape`.
Single values should be denoted by None or ()

setpoints: (3,4,5) the setpoints for the returned array of values.
3&4 - a tuple of arrays. The first array is be 1D, the second 2D,
etc.
5 - a tuple of tuples of arrays
Defaults to integers from zero in each respective direction
Each may be either a DataArray, a numpy array, or a sequence
(sequences will be converted to numpy arrays)
NOTE: if the setpoints will be different each measurement, leave
this out and return the setpoints (with extra names) in the get.
```

Start with the Parameter constructor and its documented .set and .get cases, especially the examples involving arrays, names, shapes, and setpoints. The issue does not identify files, tests, or a settled change; work would first require agreeing on a concrete API redesign and its documentation and compatibility criteria.

Written by the indexing model from the issue text.