Parameter class specification cleanup

[shumpohl]

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 Parametrization of pulses #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 [WIP] Parameter Namespaces [Variant B] #418 / Introduce Namespaces for Parameters #344 )

[shumpohl]

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