Clean up ion boilerplate code

[marwahaha]

This makes a concrete class IonInstance that inherits from the abstract type Ion. It is associated with a generic type, which can be specified to anything. The constructor needs a `properties' file that is only specified from a particular ion.

Then, the process to create a new ion is:

• Write out the properties (this is now a struct)
• Have a few lines of boilerplate code.

Should IonInstance should just be exactly Ion? I'm ambivalent.

---

I know that the file ions.jl is very long. I think my next project will be splitting out the files so they are much shorter -- I've noticed codebases with 2-3x more files but half as long. I think I prefer this style if there are natural "breaks" in context.

[codecov[bot]]

Codecov Report

Merging #86 (5c39698) into master (ddd827c) will increase coverage by 2.4%. The diff coverage is 73.1%.

@@           Coverage Diff            @@
##           master     #86     +/-   ##
========================================
+ Coverage    83.6%   86.0%   +2.4%     
========================================
  Files          15      15             
  Lines        1199    1149     -50     
========================================
- Hits         1002     988     -14     
+ Misses        197     161     -36     

Impacted Files	Coverage Δ
src/ions.jl	81.9% <68.2%> (-1.4%)	:arrow_down:
src/species/be9.jl	100.0% <100.0%> (+66.7%)	:arrow_up:
src/species/ca40.jl	100.0% <100.0%> (+33.3%)	:arrow_up:
src/species/mg25.jl	100.0% <100.0%> (+66.7%)	:arrow_up:
src/species/yb171.jl	33.3% <100.0%> (+3.3%)	:arrow_up:
src/operators.jl	89.4% <0.0%> (+0.7%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update ddd827c...5c39698. Read the comment docs.