Document the differences for column re-ordering in new_epi_df and as_epi_df

[rachlobay]

It probably would be good to document the differences for column re-ordering innew_epi_df and as_epi_df. For ex., new_epi_df always has column re-ordering so that the columns are geo_value, time_value ... . In contrast, as_epi_df does not appear to enforce this column re-ordering when we're already feeding an epi_df to it (it simply returns the epi_df object unchanged). But it does enforce the column re-ordering if we are converting a tbl_df, data frame, or tbl_ts to an epi_df (as it ultimately calls new_epi_df).

[brookslogan]

Copying in some notes from #183 which seem to belong better here, and proposing that we change this from just documenting difference to including a few tweaks to make the differences easier to think about (assuming that it doesn't break anything):

• I'm afraid new_epi_df vs. as_epi_df might not be clear from the roxygen docs. Perhaps the description of one or both could include a compare&contrast or rationale? (I think the most important thing to note here is the behavior on epi_dfs --- that as_epi_df will return an epi_df exactly as is, keeping the current column order and ignoring any metadata arguments, while new_epi_df will order geo_value and time_value first, and reset/overwrite --- most --- metadata.) E.g., like in ?rlang::new_quosure / ?rlang::as_quosure, tibble::new_tibble, dplyr::new_grouped_df, etc.
• Is as_of the only metadata field that new_epi_df will preserve when called on an epi_df? Do we want it that way?
• If the docs for all of the common parameters of these two functions are the same, use @inheritParams <otherfn> in one of them to not have to copy-paste all the roxygen updates. (If they're not the exact same, there are more tedious ways to reduce duplication, but maybe that could be a different issue.)
• ex3 requiring conversion away from an epi_df in order not ignore other_keys and all the other parameters seems error-prone. There is precedent with rlang::{new,as}_quosure, but still. Wondering what we should do here; maybe something like calling Abort if the user passes in metadata that doesn't match the pre-existing metadata.