API: make Timestamp/Timedelta _as_unit public as_unit
- [ ] closes #xxxx (Replace xxxx with the Github issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

@jreback mentioned this earlier this week Following today's call, I'm leaning towards changing "reso" to "creso" for the cdef methods and "unit" to "reso" for the python methods. After spending more time on this, im again really reticent to use "reso" and "as_reso" for the public keyword/attribute/method referring to the unit abbreviation (s, ms, us, ns).  "unit" is just used _everywhere_ else.  DatetimeTZDtype refers to it as .unit. numpy docs call it unit (though it isnt a keyword in the dt64/td64 constructors).  IIUC pyarrow dtypes have a .unit attribute for this.

I think the public-facing keyword/attribute/method should be unit/unit/as_unit.  The argument against has been that in the constructors this means "unit" plays two roles: 1) how to interpret int inputs, 2) how to represent the data internally.  Increasingly I think that if a user passes ints and unit="s", it makes more sense to keep this as second-resolution than cast to nanosecond (and should be more performant).  Moreover, doing this would avoid some overflow cases.

That leaves cases where a user passes a unit that is supported for input but not for storage, i.e. Y, M, D, h, m.  For these we'd treat the inputs the same and use the closest-supported (i.e. second) for storage.

Thoughts? > I think the public-facing keyword/attribute/method should be unit/unit/as_unit

Yeah I would be okay if the "problematic" situation of `to_datetime/to_timedelta/Timestamp/TImedelta(ints, unit="s")` to interpret `[ints]` as epoch seconds _and_ having the resulting unit be seconds, so having the public naming be `unit` would be okay to me. all good here?  we have the option of changing unit->reso later, but for now id like to get started on some follow-ups to this. Thanks @jbrockmendel 