Deprecate pd.*Index*(names='')
- ``pd.Index`` accepts ``name`` - great
- ``pd.MultiIndex`` accepts ``names`` - after all, they are multiple ``name``s
- ``pd.Index`` accepts ``names`` for compatibility with ``pd.MultiIndex`` - well, OK, after all, that constructor _can_ result in a ``MultiIndex``
- ``pd.Index`` should accept ( #19082 ) ``names`` even when it results in a flat index - well, OK, still for compatibility
- ``pd.MultiIndex`` accepts ``name`` for compatibility  - wait, wasn't ``names`` already provided for compatibility?! OK, forget it, go for ``name``.
- ``pd.Index`` accepts ``name`` even for multiple levels' names, for compatibility - with ``MultiIndex``, which accepts it for compatibility with ``pd.Index`` - aaaaalright
- All ``pd.Index`` subclasses (which will _never_ result in multiple levels, and which currently in some cases discard ``names``, in other cases raise an error) [should accept](https://github.com/pandas-dev/pandas/pull/19168/files#r161731210) ``names`` for compatibility - no, wait.

####  Proposal 1

1. There is _one_ way to have compatibility across any kind of ``Index`` (sub)class constructor, and it is ``name``. When the constructor results in a ``MultiIndex`` (which can happen with ``pd.Index`` or ``pd.MultiIndex``), then ``name`` should be list-like, and each level will "receive" the respective component

2. in those cases - and only in those cases - in which a constructor _actually_ results in a ``MultiIndex``, ``names`` can be used as an alias for ``name``. In all other cases, it is not accepted.

or alternatively:

2. (b) (my preference) ``names`` is deprecated (in all cases in which it is currently supported, and remains unsupported in other constructors/cases)

3. (c) (tradeoff between mental health and backward compatibility) ``names`` is supported in ``pd.MultiIndex``, still supported but deprecated in ``pd.Index`` when resulting in ``MultiIndex`` (and remains unsupported in other constructors/cases)

Corollary:

3. ``names`` will _not_ be supported by any constructor that is not ``pd.Index`` or ``pd.MultiIndex``.

Notice that a 1-level ``MultiIndex`` is still a ``MultiIndex``. That is,

- ``pd.Index([('a',), ('b',)], name=('only_one_name',))`` will still work
- ``pd.Index([('a',), ('b',)], names=('only_one_name',))`` will still work (at least as long as we don't deprecate ``names`` entirely)
- ``pd.Index([('a',), ('b',)], name='only_one_name')`` will still _not_ work

####  Proposal 2

1. There is _one_ way to have compatibility across any kind of ``Index`` (sub)class constructor, and it is ``names``, which must _always_ be list-like.

2. In those cases in which the constructor results in a flat index, ``name`` is also accepted, and interpreted as ``names=(name,)``; instead ``name`` is deprecated for ``pd.MultiIndex``, and for ``pd.Index`` when resulting in a ``MultiIndex`` (_even if_ with 1 level)

Corollary:

3. implementation-wise, we will want to decorate all ``__new__`` of non-``MultiIndex`` subclasses to convert ``names`` to ``name``