Use Kinematics.get_data() instead of Kinematics.data in DYNAMITE where possible

This PR minimizes direct access to the Kinematics.data attribute and replacing it by calling the Kinematics.get_data(...) method.

Rationale:

For GH kinematics, the attribute Kinematics.data contains the input data as read from disk, whereas Kinematics.get_data(...) (a) always returns the number of GH coefficients number_GH specified in the configuration file and (b) if instructed, applies the systematic errors GH_sys_err specified in the configuration file.
For other kinematics (currently BayesLOSVD), .get_data() returns a deep copy of the kinematics data.
For consistency,Kinematics.get_data() should be used across DYNAMITE whenever kinematics data is accessed.

Notes:

If 'dummy kinematics objects' are required, directly accessing the .data attribute will still be necessary (such as in weight_solver.py lines 189+ and analysis.py line 558). Is this reason enough to implement an option to instantiate a Kinematics object with the underlying data passed as an astropy table instead of a filename?
Implemented a new attribute Kinematics.n_spatial_bins that can be used independent of the Kinematics type. For GaussHermite, it is the same as .n_apertures.

Tested with test_nnls.py and test_notebooks.py.

Closes #337.

dynamics-of-stellar-systems / dynamite