Resolve symmetric migrations into pairs of asymmetric migrations.

[grahamgower]

Also restores the migration simplification code that was removed
in commit e2a7e05 (#209).

Closes #263.

[github-actions]

👈 Launch a binder notebook on this branch for commit e92bc57

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit ed105ea

[codecov]

Codecov Report

Merging #268 (ed105ea) into main (db58a7b) will increase coverage by 0.54%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #268      +/-   ##
==========================================
+ Coverage   96.14%   96.69%   +0.54%     
==========================================
  Files           7        7              
  Lines        1064     1058       -6     
==========================================
  Hits         1023     1023              
+ Misses         41       35       -6     

Impacted Files	Coverage Δ
demes/__init__.py	87.50% <ø> (ø)
demes/convert/msprime_.py	92.98% <100.00%> (+3.09%)	⬆️
demes/demes.py	100.00% <100.00%> (ø)

---

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 db58a7b...ed105ea. Read the comment docs.

[apragsdale]

This looks great to me! Lots of fiddling, but I think it will end up simplifying things again quite a bit. I also like that it gets the migration simplification back in there when using asdict_simplified :)

[apragsdale]

If we only have AsymmetricMigration as the internal continuous migration class, should we call it simply Migration? Or leave it as AsymmetricMigration so that we leave open the option of reintroducing SymmetricMigration?

[grahamgower]

Yeah, good question. I left it as AsymmetricMigration initially because it was easiest at the first stage of refactoring. But having this be explicit might help reduce confusion (at the expense of verbosity). And as you say, its not implausible that we'd introduce something called SymmetricMigration again in the future. But I don't have a strong opinion on what this should be called.

[apragsdale]

Perfect, it was more of a question than suggestion that we should change it anyway. I'm happy to keep it as AsymmetricMigration, as it does reduce any possible confusion (and also allows us to introduce a SymmetricMigration if we are compelled to in the future again). Most users will still just see the add_migration function in the Builder, and won't even know how it is being represented behind the scene, I imagine.