FIX preserve dtype with datetime columns of different resolution when merging
- [x] closes #53200
- [x] [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
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Avoid coercing to `object` dtype when merging datetime columns with different resolutions. Instead, use the most fine-grain resolution.
thx @glemaitre  Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 2.0.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -x -m1 935244a9b9c0fe796de315cd381d6364719bfdc1
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #53213: FIX preserve dtype with datetime columns of different resolution when merging'
```

4. Push to a named branch:

```
git push YOURFORK 2.0.x:auto-backport-of-pr-53213-on-2.0.x
```

5. Create a PR against branch 2.0.x, I would have named this PR:

> "Backport PR #53213 on branch 2.0.x (FIX preserve dtype with datetime columns of different resolution when merging)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                 One aspect we were still looking into was that the _reason_ this is correctly working for tz-naive datetimes with different resolutions is only because the merging uses the object factorizer (at which point the different resolution doesn't matter). We should also call `_ensure_matching_resos` for tz-naive data somewhere as well.

This also seems to point to a performance regression from 1.5 to 2.0, as looking a bit into it, it seems we are actually also using the object factorizer even for datetimes with the same resolution.

Will do a follow-up PR Performance fix -> https://github.com/pandas-dev/pandas/pull/53231

There was also one more situation I noticed where we incorrectly cast to object dtype, and that's for an outer/right join if the join key column needs to be combined. Possible short-term workaround -> https://github.com/pandas-dev/pandas/pull/53233