WIP/API: Make Day not a Tick
- [x] closes #41943 (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.

Still have a handful of failing tests and a bunch of ugly kludges.

With a second rc next week, we potentially have a second chance to get this in for 2.0.  Largely posting this to get @mroeschke's thoughts on if it is worth trying to get this in. 
On first glance, I am a little surprised how much `isinstance(offset, Day)` special casing we still need, unless those are kludges (I would have hoped making it a calendar day would have provided some simplifications).

I am on the fence for rushing to get this into the second 2.0rc; personally I haven't fully comprehended all the implication of telling users to migrate from n * Days -> 24 * n Hours which seems like may touch a lot of areas I'm not aware of. More cleanup to do, but I'm more optimistic about this than I was a day or two ago.

Some of the diff will be reduced by separately addressing a pre-existing bug in resample incorrectly allowing non-Tick offsets in TimedeltaIndex. We could probably restore+deprecate Day multiplication and division, maybe also Timedelta(Day) and Day.nanos Some of this will be unnecessary with #51896 +1 on the idea, but isn't it a bit big to get into the RC at this point? > but isn't it a bit big to get into the RC at this point?

Yes, that's why I want buy-in!

This is a bug that @mroeschke and I have been trying to fix on and off since 2018.  I only finally got a branch working a few days ago. Yeah while I want to see this fixed too, I also think this is a lot for the RC2 in a few days.

Additionally, maybe we can think of a more holistic change for 3.0 that may simplify this more; deprecating Ticks all together and introducing a CalendayDay frequency. Fair enough.  I'll try to keep this green until the 3.0 merge window opens, maybe we can chip away at it with deprecations in the interim. ```
Error: None:None:GL01:pandas.tseries.offsets.Day.rule_code:Docstring text (summary) should start in the line immediately after the opening quotes (not in the same line, or leaving a blank line in between)
Error: None:None:GL02:pandas.tseries.offsets.Day.rule_code:Closing quotes should be placed in the line after the last text in the docstring (do not close the quotes in the same line as the text, or leave a blank line between the last text and the quotes)
Error: None:None:SS02:pandas.tseries.offsets.Day.rule_code:Summary does not start with a capital letter
Error: None:None:SS03:pandas.tseries.offsets.Day.rule_code:Summary does not end with a period
Error: None:None:SS06:pandas.tseries.offsets.Day.rule_code:Summary should fit in a single line
```

It looks like the linter is mistaking a non-docstring string for a docstring.  @MarcoGorelli is this from the cython linter you implemented? > rule_code

nope, it's from `scripts/validate_docstrings.py` is this ready for review? just asking because of the 'wip' in the title > is this ready for review? just asking because of the 'wip' in the title

Ambiguous.  It is a breaking change to be merged for 3.0. I made a PR on the theory that keeping it green for a year would be easier than rebasing it _in_ a year.  Ideally we can find some bits to break off as deprecations in the interim.

So reviews are welcome, but definitely not a priority. +1 to keep doing this Closing in favor of #55502