put binary derived state into the mutation table metadata

[bhaller]

This PR fixes #664 (I hope). Review requested from @petrelharp. Right now I've tested that it round-trips a tree sequence out to disk and back, and that seems to work AFAICT. Let me know if it does what you need it to do.

Also, note: it does what it does in an unorthodox way, by munging around inside the tskit data structures, because I didn't want to be making copies of this stuff – the derived state column could potentially be a pretty big buffer, so I didn't want to push the high-water memory usage mark higher if possible. If there is a cleaner and more orthodox way to do what I'm doing, that would be great of course. In any case, please make sure that the way that I'm munging tskit's data structures is completely correct and safe (given the current tskit implementation). This code ought to be bulletproof, of course, but I'm not sure that it is since I don't feel 100% confident in my understanding of how tskit does things under the hood (and AFAIK that is not documented anywhere, even in comments, right?).

[bhaller]

And again GitHub Desktop has based this PR on master instead of multitrait. I definitely told the GUI to base it off of multitrait; I was careful! So, hmm, annoying. Can you fix it up again, however you do that, @petrelharp? (Is there UI in GitHub to do it, somewhere?) [EDIT: Found the UI, which is quite hidden! You have to click the "Edit title" button, and having done that, a popup appears that lets you choose the branch the PR will be merged into. Their UI designers were smoking something when they came up with that! :-O]

[codecov]

Codecov Report

❌ Patch coverage is 94.11765% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.92%. Comparing base (3d2c471) to head (f31ec10).

Files with missing lines	Patch %	Lines
core/species.cpp	94.11%	3 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff               @@
##           multitrait     #665      +/-   ##
==============================================
+ Coverage       76.86%   76.92%   +0.06%     
==============================================
  Files             117      117              
  Lines           78747    78732      -15     
  Branches        14299    14300       +1     
==============================================
+ Hits            60528    60568      +40     
+ Misses          18219    18164      -55     

Files with missing lines	Coverage Δ
core/slim_globals.cpp	69.25% <ø> (+0.16%)	⬆️
core/species.h	91.80% <ø> (ø)
core/species.cpp	64.68% <94.11%> (-0.07%)	⬇️

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bhaller]

Hmm. The branch that this PR is based on, derived_state_metadata, still appears to be based on master. So maybe this is still screwed up. I'm going to just delete this PR, and its associated branch, and try again. Grr.

[bhaller]

OK, clearly I'm (yet again) fundamentally confused by Git's conceptual model. I just made a new branch, derived_state_metadata_2, based on multitrait. I published that branch. If I now look at it in GitHub, it says "This branch is 335 commits ahead of master." I was expecting it to say "This branch is 0 commits ahead of multitrait." Why is it comparing itself to master?? But if I go to Terminal and do git reflog show derived_state_metadata_2, it says "Created from multitrait", and it looks like HEAD for derived_state_metadata_2 points to the current head of multitrait. Aargh, so confusing. So I'm going to hypothesize that the original derived_state_metadata branch was OK, and that once I switched this PR over to being based against master (why didn't it base off of multitrait, since it knows that derived_state_metadata is a branch off of multitrait??), now this PR is also OK. So I'm going to reopen this PR, and delete my derived_state_metadata_2 branch. But it'd be helpful to understand why Git is acting this way, and to be reassured that merging this PR will not somehow corrupt the project. Grr, grr.