BUG/API: Series(dt64tz_data, dtype="datetime64[ns]") behavior inconsistent
In principle if a user passes dt64tz data and tznaive dtype we should raise (like we do for DatetimeIndex) and tell the user to use `dt.tz_localize`.

In practice, we cast in some but not all cases.  The first two cases here we specifically test for (xref #25843):

```
ts = pd.Timestamp("2019", tz="US/Eastern")
ts_naive = pd.Timestamp("2019")

exp_df = pd.DataFrame({"d": [ts_naive]})
exp_ser = pd.Series([ts_naive])


#  These first two we explicitly test for
df = pd.DataFrame({"d": [ts]}, dtype="datetime64[ns]")
tm.assert_equal(df, exp_df)

ser = pd.Series([ts], dtype="datetime64[ns]")
tm.assert_equal(ser, exp_ser)

# The next three we don't explicitly test for, but works
df = pd.DataFrame([ts], columns=["d"], dtype="datetime64[ns]")
tm.assert_equal(df, exp_df)

ser = pd.Series({0: ts}, dtype="datetime64[ns]")
tm.assert_equal(ser, exp_ser)

ser = pd.Series(ts, dtype="datetime64[ns]")
tm.assert_equal(ser, exp_ser)

# The the rest do cast to tznaive, but are off by 5 hours

df = pd.DataFrame({"d": ts}, index=[0], dtype="datetime64[ns]")
tm.assert_equal(df, exp_df)  # <--raises

df = pd.DataFrame(ts, index=[0], columns=["d"], dtype="datetime64[ns]")
tm.assert_equal(df, exp_df)  # <--raises

ser = pd.Series(ts, index=[0], dtype="datetime64[ns]")
tm.assert_equal(df, exp_df)  # <--raises

# If we wrap in a tz-aware Series first we get a FutureWarning bc of astype deprecation, followed by being off by 5 hours

aware = pd.Series([ts])
ser = pd.Series(aware, dtype="datetime64[ns]")
tm.assert_equal(df, exp_df)  # <--raises
```

The "working" cases are due to a check in `maybe_cast_to_datetime`:

```
 if is_datetime64:   # <-- i.e. requested dtype is tznaive
    dti = to_datetime(value, errors="raise")
    # GH 25843: Remove tz information since the dtype
    # didn't specify one
    if dti.tz is not None:
        dti = dti.tz_localize(None)
```

If these were all consistent, I'd want to deprecate just like we have for astype.  But with the inconsistency, we might want to call it a bugfix.