Change which epi_archive operations have reference semantics

[brookslogan]

Two potential approaches:

• change epi_archive from an R6 class into an S3-classed-list containing a lazy_dt (from dtplyr)
• rename current epi_archive R6 class to EpiArchive, make epi_archive an S3 list wrapper on top of EpiArchive that somehow prevents reference semantics from messing with users

Main complication:

• We may eventually want disk-backed and/or updating epi_archives for delphi-epidata, WayBack Machine, GitHub, and/or other types of data sources; if these are also considered epi_archives rather than their own separate class, we want to ensure that they will have a sensible and compatible non-reference-semantics or side-effect-based interface

Other work:

• Update docs and vignettes talking about R6 and reference semantics.

[brookslogan]

The priority of this issue might be upgraded depending on feelings on #64.

[brookslogan]

We discussed an alternative approach to this:

• archive$function is potentially effectful (and may often have invisible output)
• archive %>% function_potentially_with_another_name is not effectful (often may just clone first) (and is does not often produce invisible output)
• merge should not have side effects on the first argument as it does now

[ryantibs]

@lcbrooks Yes I'm currently in favor of the alternative approach. And I added something to #64 that is also consistent with this.

So I think it currently only remains to change merge() and epix_merge() to make them abide by the new philosophy. To be clear, here's what I'm thinking:

• x$merge(y) should merge x and y, and overwrite x with the result.
• epix_merge(x, y) should merge x and y, and return new epi_archive with the result, whose data table is a NEW object. That is, x and y are completely unchanged (as are their underlying data tables).

Thoughts?

[brookslogan]

I believe the "alternative approach" was completed for the currently available operations in #101. Any further discussion / revisiting is moved to #181.