Fix failing tests/behavior when `dtplyr` < 1.3 is loaded, any mem violations if not

[brookslogan]

When given a data.table as input, the output of many dplyr verbs changes when dtplyr is loaded, e.g., outputting dtplyr_steps. These steps need to be converted back into the class they were without dtplyr loaded in order to be robust to dtplyr being loaded.

[brookslogan]

These tests probably no longer fail as of dtplyr 1.3.0. However, we should still fix them and any package code that uses tibble/dplyr functions directly on data.tables that might mutate columns in-place with smart CoW (assuming no column aliases or descendant aliases naturally exist or have been set up to force copying... this might actually be a given though) or store the result, as these could mess up either the original data.table. (Similar/related notes here.)

[brookslogan]

To clarify here, more of the worry now is that dplyr operations called on data.tables without dtplyr loaded (and potentially with dtplyr >= 1.3.0 loaded) are going to violate data.table's memory model, and R optimizations may result in unintended mutation of (parts of) the data.table fed into them.

Transitioning to use dtplyr >= 1.3.0 lazy_dts would be one way to not have to think so hard about this, if performant.