Fixturize JSON tests
Ultimately looking to split this module up into something like:

 - test_serializer.py
 - test_deserializer.py
 - test_roundtrip.py
 - test_orient.py

TBD on those being the actual modules, but for now starting with some parametrization
> we had basically these same fixtures, then removed them, now are adding them back (in pandas/conftest.py)

With the exception of `empty_series` this isn't adding anything but instead moving from pandas/tests/series/conftest.py to the higher level conftest for re-use. Can alternately duplicate definitions in JSON conftest if we don't like them at the high level, but note that there are quite a few other tests areas that could reuse these rather than calling `tm.make*` functions directly > > we had basically these same fixtures, then removed them, now are adding them back (in pandas/conftest.py)
> 
> With the exception of `empty_series` this isn't adding anything but instead moving from pandas/tests/series/conftest.py to the higher level conftest for re-use. Can alternately duplicate definitions in JSON conftest if we don't like them at the high level, but note that there are quite a few other tests areas that could reuse these rather than calling `tm.make*` functions directly

i think you are not seeing the big picture here. I am all for making fixtures top-level and not speciying them at a lower level. However, we have had a number of PRs moving them to lower levels, and then others moving them up.

Before we merge this we need a check to avoid duplication of fixtures. Ah OK I get what you are asking. So running `pytest pandas --fixtures` and searching for these would manually confirm they aren't duplicated. I'll check with the pytest folks to see if they offer anything more robust needs rebase unused import, otherwise LGTM needs rebase, ping on green cc @jreback im about ready to merge this, any objection? can you merge master and see if you can avoid the monkeypatch > Having different fixtures with the same name shouldn't cause conflicts if the directory structure is properly organised and in this case I see no reason to rename it.

I don't think we are worried about this causing errors as much as being confusing; I don't know that we want to override fixtures in different packages, and Jeff was asking previously for some way to check that we explicitly don't do this (unless I misunderstood)

> If you are renaming can you avoid the use of dti? maybe empty_series_datetimelike.

These are all empty series with datetimelike-typed indices, which is why I went for dti. I personally would misread `series_datetimelike` as referring to the values not the indices; @jbrockmendel since you have the most expertise in that area - can you offer an opinion? > I personally would misread series_datetimelike as referring to the values not the indices

I would be at risk of this too.

This naming convention problem is not easy and is not unique to this PR, should not hold it up.

AFAICT there are three options for getting informative names:
1) long names e.g. "datetime64_series_with_interval_index"
2) adopt some predictable conventions to shorten these e.g. "dt64ser_ii"
3) live with the not-really-that-bad status quo lgtm. am a little concerted about changing to use empty_series_dti, but agree we need to fix this; so ok for now (maybe open a followup issue for discussion).

any more @simonjayhawkins or @jbrockmendel  im a happy camper Thanks @WillAyd 