Improving the NCDFWriter behaviour (units + scale_factors)

[IAlibay]

Is your feature request related to a problem? Please describe.
A discussed in PR #2326, improving the NCDFReader has highlighted the fact that the NCDFWriter probably needs to be updated to ensure consistency with the AMBER NCDF convention (http://ambermd.org/netcdf/nctraj.xhtml) and the way AMBER MD engines write out certain variables by default.

Notably the following questions/issues have been raised:

• The writer currently writes out cell_angles in units of degrees unlike the convention agreed degree.
• The writer currently writes out velocities directly in whatever values MDAnalysis holds (usually units of Angstrom/ps). However, the standard behaviour of the AMBER MD engines appears to be to store the values in Angstrom/AKMA time units with a scale_factor of 20.455 in order to yield Angstrom/ps values when multiplied through. Assuming all readers properly implement the AMBER NetCDF convention and/or display scaled values to users, this should not be an issue. However in practice this is not actually the case (see this conversation for an example where things can easily become confusing: http://archive.ambermd.org/201908/0067.html).

Describe the solution you'd like
As discussed with @orbeckst the current plan is to:

• Change the units of cell_angles to degree, deprecate the reading of degrees and remove it from MDAnalysis 1.0 onwards. (Addressed by Changes cell_angle units to degree (Issue #2327) #2339 )
• Default the writing style to that of trajectories written by the AMBER MD engines (or at least pmemd as of Amber 18 + AmberTools 19).
• Implement an option for the writer to pick up whatever scale_factors were used on read, and allow for user-defined values too.

Additional context
Work on a PR related to this will begin after #2326.

[orbeckst]

I labeled it as defect because "degrees" is wrong. The other solutions are better choices than what we have so far. The reading of degrees was already deprecated in PR #2326 .

[IAlibay]

We probably should fix this for for 2.0. In the interest of changing the way that velocities are written, do we think it's worth adding a warning in 1.0.2 that the velocity writing behaviour is going to change? (I'm reluctant to just add all the warnings, but at the same time doing this without warning is probably a bad idea).

[orbeckst]

I agree that we should have a warning 1.0.2 — if nothing else we can then say that we warned everyone.