Fix recursive gc error that could occur with POSIXct columns

[DavisVaughan]

Closes #389

The analysis in this comment was correct #389 (comment), the output_column() method for POSIXct was creating another character ALTREP vector after vroom_convert() was called.

I didn't add a test, because this is hard to test for, but I confirmed that the reprex here no longer errors #389 (comment)

---

POSIXct isn't necessarily the only type where this could happen.

output_column.POSIXt() calls format(), and what is happening in format() is:

• There is some C code that converts POSIXct -> character and returns a non-altrep character vector called y
• At the R level, there is some code that adds names onto y
• names<- at the C level will create an “ALTREP wrapper” around y. It allows you to wrap y without duplicating it, and then add new attributes on top of it (like names) cheaply

# part of format.POSIXlt
y <- .Internal(format.POSIXlt(x, format, usetz))
names(y) <- names(x$year)

• There is additionally a structure() call in format.POSIXct() that tries to add names on again to the result of format.POSIXlt(). This is probably also creating another ALTREP wrapper layer on top of the first one.

# part of format.POSIXct
structure(format.POSIXlt(as.POSIXlt(x, tz), format, usetz,  ...), names = names(x))

So it is entirely possible that other output_column() methods could do this, but I don’t think any of the currently implemented ones do.

[romainfrancois]

LGTM

[jennybc]

It's too bad we can't add a test, but I agree that it's impractical.

I've tried to look at this with a Chesterton's Fence perspective and it seems likely that the initial order (materialize, convert to character) seemed most natural and it's easy to overlook that character conversion can re-introduce ALTREP vectors (especially since POSIXt may be the only current example).