Add separate epi_archive constructor based on a "iterator"/list/df of snapshots

[brookslogan]

See #172 for background. This would work around some of the caveats noted there by:

• Detecting row deletions, probably just representing them as an update row with all non-key columns NA.
• For each explicit version, check whether a snapshot of next_after(version) was provided. If not, insert a snapshot revising all observations to NA with this version tag (next_after(version)). ---- This is pretty inefficient space-wise. Maybe we would want to do something with the design of epi_archive to make more efficient options available.

[brookslogan]

We can be a lot more memory-friendly than an in-memory list/df of snapshots, by only reading in one / a few snapshots at a time, and compactifying along the way (plus suggesting to save the compactified version on disk if we compactified a lot, or more complicated things regarding proposed "updating" archives that are out of scope for this initial feature).

[brookslogan]

Status: I have the iterator stuff ready in a separate repo + a version of a map_ea. Documenting, testing, and refactoring to reduce duplication with existing stuff means it will still take some work to incorporate. The extent of refactoring and how much to split off to another time TBD.

[brookslogan]

Going to punt this down the road in favor of doc updates. See map_ea here, iterators here (iterb approach seems probably preferable), and tbl_{diff2,patch} in #611.