API: tighten DTA/TDA _from_sequence signature
cc @jorisvandenbossche 

need to decide how to handle test_from_2d_ndarray_with_dtype which this currently xfails
> this looks like a substantial (but good) api change, or is this _just_ on master as _from_sequence is actually strict? (in 1.1.x)

not just on master, this makes _from_sequence substantially stricter than 1.1.x Thanks for looking at this!

Now, for the actual behavioural change, `_from_sequence` is still being used for eg `pd.array(.., dtype="datetime64[ns"])` as well, so we first need to decide what behaviour we want for that. 
Otherwise could also keep this in a `_from_sequence_strict` (and rename `_from_sequence_not_strict` to `_from_sequence`) just pushed with a couple new tests that get us to full coverage on the affected methods if u can rebase; i think a couple of questions cc @WillAyd most recent commit made small edits to json code, can you take a look lgtm - I think the explicitness here is nice @jorisvandenbossche any objection to this as a temporary workaround?  im pretty sure It will allow us to clean up a bunch of code in .isin and .equals xref #37528 updated per discussion so that _from_sequence remains non-strict while a new _from_sequence_strict has the hopefully-future behavior of from_sequence.

im hoping to use from_sequence strict to simplify+de-duplicate .equals and .isin > We don't have one that is more strict on the input that could be used for this purpose?

Good idea, we can use `tslibs.conversion.datetime_to_datetime64`.  AFAICT we dont have an equivalent for timedelta, but it wouldn't be hard to implement one.  `libperiod.extract_ordinals` can also be adapted to do the same thing for PeriodArray (separate PR).

Will update. mothballing to clear the queue while i address comments locally