DEPR: Timestamp.freq
- [x] closes #15146
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

The motivation here is that I've concluded that DatetimeArray.freq _must_ be removed, so for internal consistency Timestamp.freq should be removed too.

The main user-facing behavior this will affect is Timestamp.is_month_start, is_month_end, is_quarter_start, is_quarter_end, is_year_start, is_year_end, for which I guess we'll offer users an alternative(?)
> The main user-facing behavior this will affect is Timestamp.is_month_start, is_month_end, is_quarter_start, is_quarter_end, is_year_start, is_year_end, for which I guess we'll offer users an alternative(?)

I think all of these can be defined without frequency. Looks like there's already "no frequency" code path for these

```
        if self.freq is None:
            # fast-path for non-business frequencies
            return self.day == 1 and self.month % 3 == 1
``` can you link to the deprecation removal issue as well > I think all of these can be defined without frequency. Looks like there's already "no frequency" code path for these

You're right.  The potential issue is if users want to get the old (i.e. current) behavior that as if there were a freq.  I guess we can tell them to do `DatetimeIndex([ts], freq=freq).whatever` The current PR seems to generate a lot of warnings (from looking at the test changes) that shouldn't be propagated to the user? 
(eg boxing a DatetimeIndex, converting to object dtyp, ... And I also noticed that accessing a single element from a DatetimeIndex raises the warning, and the DatetimeIndex repr, ...) 

> The main user-facing behavior this will affect is Timestamp.is_month_start, is_month_end, is_quarter_start, is_quarter_end, is_year_start, is_year_end, for which I guess we'll offer users an alternative(?)

Can you show with an example what is actually changing here? closing to clear the queue