Fix presence matrix calculation (and derived values)

[ivirshup]

Fixes #1284

This PR addresses issues with presence matrix calculation. Previously only genes with non-zero values were included in the presence matrix, while the intent was to include all genes recorded in the original anndata.

Previously, the test cases had all non-zero values. This meant that the "non-zero" and "present" genes overlapped completely. We now include some zeros in the test cases, which caused the existing tests to fail before I implemented a fix.

Evidence this works: https://gist.github.com/ivirshup/4c09193e30534bdcfe9710efed4f2b16

---

I think there is also a broader code cleanup that could happen. Broadly, I find the statistics calculation hard to follow (many classes, deferred calculations). But what could be in scope is cleaning up unused attributes, classes, and code related to presence matrix construction.

[codecov]

Codecov Report

Attention: Patch coverage is 91.17647% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.42%. Comparing base (fbb00fe) to head (d9889db).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...llxgene_census_builder/build_soma/validate_soma.py	82.35%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1320      +/-   ##
==========================================
+ Coverage   91.35%   91.42%   +0.07%     
==========================================
  Files          82       82              
  Lines        6480     6487       +7     
==========================================
+ Hits         5920     5931      +11     
+ Misses        560      556       -4     

Flag	Coverage Δ
unittests	91.42% <91.17%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ivirshup]

So, I was adding a little more validation to #1320 and ended up in an odd situation. The validation I added seemed to contradict some existing code which was (AFAICT) validating the previous incorrect state. Yet: no validation errors with all code present.

After banging my head against it, I paired with @ebezzi and we figured out that this line ends up meaning that this whole validation step is never actually run (though it is logged as running, it just ends up being a no-op).

This is now fixed in 4a7ed8f