BUG: Fix insertion of wrong-dtypes NaT into Series[m8ns]
Broken off from #27311 to troubleshoot build-specific failures.  Also re-wrote test to parametrize and be more succinct
> not sure I agree with the point of this PR. the np.* based 'NaT' should never exist in pandas at all, ever, we simply need to cast them appropriately

xref #24983.  What you are suggesting is 100% impossible to do correctly.

> I get that you want to turn an M8 array when presented with an m8('NaT') into object, but I do't think we currently do

Well you're right that it is not what we currently do, but that is a bug.  It is unambiguously the correct behavior.

> However I don't view this distinct as very import and it adds a lot of complexity

It's your prerogative (a word whose spelling never ceases to amaze me) to consider it a low-priority bug.  On the flip side, I see complexity stemming from the fact that we have to guess what dtype NaT is behaving as in any given situation, and the impossibility of always guessing correctly.

> We now treat NaT, np.nan, None and np.*('nat') synonymously as missing values when presented to say a M8 (or a m8); I don't see why we don't simply say, hey I have a missig value, great use the value for this dtype.

Consider: if a user passes `pd.NaT`, that does basically your "hey I have a missing value" thing.  But if a user _specifically_ passes `np.datetime64("NaT")`, they did that on purpose. changed test class to just a function rebased following can_hold_element fix gentle ping; this one is a bugfix, admittedly a small one sure thanks @jbrockmendel 