Derived parameter classes

[FKirton]

Review the use and architecture of the derived parameter classes SEFD, AtmosphereParams, Efficiencies, Temperatures.

• Does it make sense for these to exist as separate classes, or would it be better to have a class that was responsible for perfoming all calculations (including sensitivity and integration time), that is a (private) member of the main Calculator class? Is there a foreseeable usecase where it would be helpful to have separate classes that encapsulate the different categories of parameter (keep in mind that the Calculator class currently provides access to all parameters, so as things currently are, certain parameters are being duplicated across different classes. Also keep in mind that in the currentl implementation, the objects instantiated by the calculator are not accessible outside the class, so they're not providing any real benefit).
• If the classes are to be retained, look in more detail at their implementation. Currently, they're behaviour/interfaces are not consistent (e.g., methods vs property for getters for accessing calculated parameters).

[FKirton]

Note that SEFD class has been removed as part of issue #50. The calculated value is accessible via the derived parameters stored in the calulator, so this class is redundant.

[FKirton]

The remaining classes have been retained, but have been simplified and tidied up. They're used to perform calculations and only provide accessors for parameters that are subsequently used for other calculations.