[DOC] Centralize and clarify documentation on mutation, compactification, and other footguns

[dshemetov]

There are a number of gotchas and footguns available for our users. We want to warn them, but we shouldn't overload them. Let's write a "cautions" document and link to that in the rest of the documentation.

Some previous ideas:

• It's generally unsafe for a user to modify epi_archive internals on their own. Use epiprocess functions whenever possible. epi_archive$clobberable_versions_start <- ... will not go through validation like it does on construction. Same goes for all the other attributes.
• Partial attribute matching can occur: archive_cases_dv_subset$version will partial match to archive_cases_dv_subset$versions_end.
• Maybe a "For data.table users:" section. "Reseating" (not sure what this means)
• see the "Compactify" doc section after wip feat: replace R6 epi_archive with S3 implementation #431 is merged

[brookslogan]

• Reseat = mutate pointer to point to something different.
  • If you definitely reseat to an unaliased object, then you can do mutation of the "pointee" without as much worry, and can also "move" it / give ownership of it away assuming that you own the pointer & don't use it again.
  • If you potentially reseat, then you cannot do aliased mutation for the purpose of modifying the original pointee.
  • [This is a different concern set than if you mutated the pointee; e.g., in that case you may worry about whether the pointee is aliased, whereas if you definitely reseat & definitely don't mutate the original pointee you don't care whether you were originally aliasing.]

Compactify doc seems like an okay stop-gap. Hoping that we can add a filter implementation, then encapsulate DT and provide only something like a get_diff_data() so that we can just compactify and not talk about it when people are constructing the archive.