Fix scalar iloc
 - [x] closes #15686
 - [x] tests added / passed
 - [x] passes ``git diff master --name-only -- '*.py' | flake8 --diff``
 - [x] whatsnew entry

Unless I'm missing anything, all code for indexers (inside ``pandas/core/indexing.py``) resorts to one of the following for setting values:
- if we can work directly on ``BlockManager.setitem`` (simple case, e.g. no multiple dtypes involved), do so
- otherwise, rely on methods provided by the object (mainly ``__setitem__``), _which are label based_

This makes it impossible, in the "non-simple case", to index positionally in the correct way with duplicated labels (by the way, it's also plain ugly).

I can see three (four) possible solutions:
1. temporarily strip an object from (some of) its labels - what this PR does. Arguably the simplest approach (doesn't require changing objects/``BlockManager`` code), arguably not very elegant (although we could already expect some efficiency gains compared to current master, since this removes some equality checks on labels)
2. add methods to the different objects that do position-based setting. Not trivial as it sounds, I'm afraid - such methods should talk directly the the ``BlockManager``s, hence for instance taking care of dtype changes
3. seriously improving ``BlockManager.setitem`` so that it is able to take care of multiple dtypes. Probably the best approach (would allow to enormously simplify indexing code), and the one requiring most work
4. (completely rewrite all setting code in ``indexing.py`` currently relying on ``self.obj.__setitem__`` so it directly talks to ``BlockManager.setitem``)

Notice that ``BlockManager.setitem`` must be fixed in order to fix #12991, but the fix for that bug is significantly simpler than 3. (it is just a matter of shifting indices, not of working with different dtypes).

The current PR... works, and does clean a bit the ``_setter`` interface (i.e. concerning the difference between ``iloc`` and ``loc``), which might be a good thing even in case we later decide to drop the less elegant ``InfoCleaner``. My preferred approach would be to apply it, then start working on 3., then come back to the indexing code and simplify it by profiting of 3. But if you prefer to start directly with 2. or 3., I can have a try in that direction. I don't think I'm willing to try 4. because current indexing code is already too complicated.