 BUG: parsing mixed-offset Timestamps with errors='ignore' and no format raises 
This is a refactor I'd been wanting to do for a while. Fortunately, it closes #50585, and also addresses the performance issue reported in https://github.com/pandas-dev/pandas/issues/35296#issuecomment-1371347855

- [ ] closes #50585  (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.

I'd highly recommend setting "ignore whitespace" when reviewing this
sure - it's actually changed already, because I've removed the try-except (within the try-except, within the try-except...who'd have thought all these nested try-excepts would cause issues 😄 ) which re-reraised ValueError as TypeError - now the original error is raised (see one of the fixed tests)

---

The performance gain on the snippet from #35296 is huge here BTW:

1.5.2:
```python
In [4]: %%time
   ...: df = pd.read_csv(csv_file, usecols=['ts_col'],
   ...:     date_parser=lambda x: pd.to_datetime(x, format=timestamp_format),
   ...:     parse_dates=['ts_col']
   ...: )
   ...:
   ...:
<timed exec>:1: FutureWarning:
        Use pd.to_datetime instead.

CPU times: user 21.7 s, sys: 9.87 ms, total: 21.7 s
Wall time: 21.7 s
```

Here:
```python
In [2]: %%time
   ...: 
   ...: df = pd.read_csv(csv_file, usecols=['ts_col'],
   ...:     date_parser=lambda x: pd.to_datetime(x, format=timestamp_format),
   ...:     parse_dates=['ts_col']
   ...: )
   ...: 
   ...: 
CPU times: user 306 ms, sys: 22.9 ms, total: 329 ms
Wall time: 331 ms
```

Thanks @sm-Fifteen for your report, this was really useful! Thanks @MarcoGorelli 