BUG: calling Timestamp constructor on Timestamp at DST changes Timestamp value
#### Code Sample, a copy-pastable example if possible

```import pandas as pd; pd.__version__

tz = "dateutil/Europe/London"
ts = pd.Timestamp("2013-10-27 01:00:00")
print("Initial value is {}".format(ts.value))
ts = ts.tz_localize(tz, ambiguous=False, nonexistent="raise")
print("After localization value is {}".format(ts.value))
ts = pd.Timestamp(ts)
print("After casting Timestamp as Timestamp value is {}".format(ts.value))

Output:
0.26.0.dev0+1608.g06c5d2488

Initial value is 1382835600000000000
After localization value is 1382835600000000000
After casting Timestamp as Timestamp value is 1382832000000000000
```
#### Problem description

TLDR: Calling the Timestamp constructor on a Timestamp shouldn't change the object in any way.

Long version: Ran into this while working on solving #30543. When we localize into a Daylight Savings Time timezone, we are forced to alter the underlying value of a Timestamp to make it fit non-DST timezones. WIthout this, date arithmetic won't work properly between timezones. This is also necessary, for example, to make sure that a `pd.date_range` with one of the ends on a DST shift doesn't break (the test for this is implemented by `test_dti_construction_ambiguous_endpoint` in `pandas.tests.indexes.datetimes.test_timezones.TestDatetimeIndexTimezones`). Unfortunately, what happens currently is that `ts.tz_localize` doesn't change the underlying value on a DST shift. It instead changes when the Timestamp constructor is called on a localized Timestamp (you can take a look, for example, [here](https://github.com/pandas-dev/pandas/blob/06c5d2488e2898497fa4767dc78a7c85ac8d19d4/pandas/core/arrays/_ranges.py#L40)).

#### Expected Output

```
Initial value is 1382835600000000000
After localization value is 1382832000000000000
After casting Timestamp as Timestamp value is 1382832000000000000
```

The value should change on localization, not on calling the constructor.
I'd like to work on a PR, because without fixing this it's impossible to solve #30543 without introducing ugly hacks.

xref: #30543