Consider adding `...` to all `as_*()` generics

[DavisVaughan]

i.e. to support things like #305

I think that as_*() is the one family of generics in clock where it could make sense to allow outside extensibility, and this often means that ... are useful for extra optional arguments when converting from some foreign type to a clock type.

---

It is likely this will cause datetimeoffset to break on CRAN with an S3 inconsistency warning, since things like datetimeoffset:::as_naive_time.datetimeoffset() exist but as_naive_time() currently doesn't have ..., so if I added them the missing ... in the datetimeoffset method would be a problem for CRAN.

This will likely be a 0.8.0 feature due to time constraints

[trevorld]

It is likely this will cause datetimeoffset to break on CRAN with an S3 inconsistency warning

I've published v0.3.1 of {datetimeoffset} tonight which should prevent an S3 inconsistency warning form occurring. For all clock as_*() methods that don't currently have a ... we now add a ... to our methods but instead of registering them via our NAMESPACE file we now register them .onLoad() using vctrs::s3_register().