[#38390] Bug fix for Datetime64Formatter with values of ndim > 1
- [x] closes #38390
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

This change fixes a bug in `Datetime64Formatter` that errors with values of ndim > 1. This was discovered when using an ExtensionArray with 2D values of datetime64 and attempting to format/display. The formatter currently allows for 2D values, but will end up returning nested strings instead of a flat list of string. The same error occurs when using the `Datetime64Formatter` directly on 2D values.

The fix is to flatten the values to get a flat list of formatted datetime64 strings, then reshape, and then format a second time over the outer dimension to produce the properly nested list format and the final flat list of strings.
Thanks for the review @jbrockmendel , sorry for the delay. I updated with a fix and tests for Datetime64TZFormatter as well, since the same bug happens. The remaining test failures look like they are unrelated from a network timeout more importantly, shouldn't this actually be handled on the EA itself? Thanks for reviewing @jreback , I just had a couple questions.

> more importantly, shouldn't this actually be handled on the EA itself?

This would be preferred, but I could not find a way to do this. When calling `repr()` on a `Series` wrapping my `ExtensionArray`, the formatting goes like this: 
1. `Series` sees the dtype is an `ExtensionType` and ends up in  `ExtensionArrayFormatter._format_strings()`
2. `ExtensionArrayFormatter._format_strings()` converts array to `numpy.ndarray`
3. `Datetime64Formatter` formats the `ndarray` into a list of strings and returns

Is there a way for the ExtensionArray to tie into this somehow? This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. > This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.

I am still planning on working this. I noticed there is a similar problem with extension arrays with floating point values of ndim > 1, so I will work on a fix that will hopefully handle both of these cases soon. This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. I haven't had the time to get back to this, will close for now and reopen when I can update