Parameter class specification cleanup

[terrorfisch]

Currently, the Parameter class in qupulse.pulses.parameter has an outdated docstring with contradicting information. The role of the parameter class itself is rather undefined.

Written documentation and discussion:

• Discussion in #14
• redthedocs: In the future, it will be possible to have parameters dependent on measurement outcomes or other events. This is the reason Parameter objects are passed through on pulse instantiation.
• Source file docstring: Parameter specifies a concrete value which is inserted instead of the parameter declaration reference in a PulseTemplate if it satisfies the minimum and maximum boundary of the corresponding ParameterDeclaration. Implementations of Parameter may provide a single constant value or obtain values by computation (e.g. from measurement results).)

Actual usage:

• The only function of the parameter class is to provide some lazy evaluation of parameter mappings

Tasks:

• [ ] Give a strong reason why we need the parameter class
• [ ] clarify the scope of the parameter class (who uses it, user facing, pulse tempalte internal)
• [ ] how can volatility be incorporated
• [ ] Discuss explicit Scope objects (See #418 / #344 )

[terrorfisch]

The Parameter class was deprecated in 0.5 and will be removed in 0.8.