ENH: add fold support to Timestamp constructor
**PERF Note:** Current implementation slows down the `Timestamp` constructor. I've tested this thoroughly and tracked it down to ba7fcd5 where I changed the function signatures at the very beginning of working on the PR. The performance overhead appeared before any of the logic was implemented.

- [X] closes #25057, closes #31338 
- [X] tests added 32 / passed 32
- [X] passes `black pandas`
- [X] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [X] whatsnew entry

### Reasoning for changes
We currently don't support fold from [PEP 495](https://www.python.org/dev/peps/pep-0495/#the-fold-attribute), and this causes us a lot of grief, including, but not limited to, broken Timestamp representations at the edge of DST shift (see #31338). The values can also break.

Support of the fold attribute helps us deal with that. Now, if the wall clock time occurs twice due to a DST shift, we will know exactly at which point in time we are.

This also removes inconsistencies between using `pytz` and `dateutil`: now both the values and representations match for both timezone packages near DST summer/winter shifts.

### Scope of PR
Implementing fold into Timestamp can easily get out of hand. Parent `pydatetime` has it easy, as the object doesn't need to sync its underlying epoch time, fold, and the representation, like we do.

This PR is already large, so I propose we limit its scope to minimal consistent fold support:
- when fold is explicitly supplied, attempt to shift value across the DST boundary according to the value supplied
- infer fold from value during tz-aware Timestamp construction. For example, if Timestamp is built from epoch time, then we can infer fold.
- pass the resulting fold to the underlying `datetime` constructor in `create_timestamp_from_ts` so that it gets stored in the object (can't assign it directly as it's read-only).
- implement local timezone support for fold. Don't have any idea how to do this though.

Things I suggest we leave to discussion and other PRs:
- conflicts resolution. A user can supply `fold=1` for a datetime that is nowhere near a DST shift. We can raise and Error or a Warning in the future. For now, we check whether `fold` can be 1, and if not, we leave it as default `fold=0`.
- consider reintroducing ambiguous time errors. Currently, the implementation assumes `fold == 0` for ambiguous time like Timestamp("2019-10-27 01:30:00", tz='Europe/London'). The error was dropped to mirror the `fold=0` default in pydatetime and to allow the fold attribute to be `bint` in Cython functions.

**Note:** `pydatetime` doesn't infer fold from value and doesn't raise errors when you assign `fold=1` nowhere near a fold. Example:

```python
from datetime import datetime
from dateutil.tz import gettz

dt = datetime.datetime(2015, 10, 27, 5, 30, 0, 0, gettz("Europe/London"), fold=1)
dt.fold
OUT:
1
```

### Performance problems
This implementation behaves as I expect it to, but it slows down scalar constructor benchmarks by 30-70%, even for tz-naive benchmarks.

Update: since the benchmark slowdown appeared before any of the functionality, this has nothing to do with the logic introduced and all to do with adding `bint fold` to function signatures, apparently. I'm afraid I don't know Cython well enough to research further.