New "Configuration Parameter"

@WilliamHPNielsen is already working on this.

Since May 7, 2017.

Based on a discussion with @damazter I would like to put forward the concept of a configuration parameter.

What is a configuration parameter?
* Behaves like a manual parameter but if it gets set changes flag `_configure_required` to `True`.
* Some other parameters call a `configure()` method whenever `_configure_required==True`.

What problem does this solve?
* Some instruments require configuration before a measurement can be started. Examples include the ATS driver and the Signal Hound. The configure command usually uses a set of parameters to at once upload/set some configuration.
* The configuration parameter allows interacting with all parameters of the instrument as if they are normal parameters while simultaneously ensuring that the instrument gets reconfigured whenever required.

I think this is a sufficiently common problem that it warrants a new parameter class. The current instruments that need it both have a different solution.

The [signal hound driver](https://github.com/QCoDeS/Qcodes/blob/master/qcodes/instrument_drivers/signal_hound/USB_SA124B.py) solves this problem by using manual parameters and the requiring the user to call the configure command by hand. The ill documentation of this functionality, combined with the missing of a simple getable parameter that represents a measurement (based on my shoddy port of an existing qtlab driver) is what initiated this discussion.

The [ATS driver](https://github.com/QCoDeS/Qcodes/blob/master/qcodes/instrument_drivers/AlazarTech/ATS.py) solves this problem by introducing an unsetable `AlazarParameter` that can only be changed using either the private method or the configure command.

I would argue that the concept of a configuration parameter is the prefered solution to this problem. However, I explicitly put this forward as a point of discussion as introducing a new concept must not be done lightly.

( @giulioungaretti, Probably intentional but I am no longer able to apply labels to issues, would make it easier to structure things a bit.)

P.S. as this issue was motivated by the low quality of a driver that I ported this raises a separate issue as to who will work on improving existing drivers, maybe an interesting subject for a discussion on Slack.