ENH: Introduce UnsortedIndexError  GH11897
closes #11897
closes #14491
 - [ ] tests added / passed
 - [ ] passes ``git diff upstream/master | flake8 --diff``
 - [ ] whatsnew entry


## [Current coverage](https://codecov.io/gh/pandas-dev/pandas/pull/14762?src=pr) is 85.28% (diff: 100%)
> Merging [#14762](https://codecov.io/gh/pandas-dev/pandas/pull/14762?src=pr) into [master](https://codecov.io/gh/pandas-dev/pandas/branch/master?src=pr) will increase coverage by **<.01%**

```diff
@@             master     #14762   diff @@
==========================================
  Files           144        144          
  Lines         50968      50970     +2   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          43466      43469     +3   
+ Misses         7502       7501     -1   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last update [2466ecb...c4e7a2a](https://codecov.io/gh/pandas-dev/pandas/compare/2466ecbb717d8cdfd30cc20d5d22e5e095d9a14d...c4e7a2aa6a110049d539d8e5196c5800976efb78?src=pr) @Dr-Irv lgtm. just a couple of minor points. ping when green.

@jorisvandenbossche  i think we can expose errors in

pandas.api.errors

but will need to do in another PR (need tests i think)

and a deprecation message if importerd
from core.common (which i think will work) > and a deprecation message if importerd

Well, there was a PR from gfyoung couple weeks ago about deprecating an exception, and turned out to be not that easy. 
That's also the reason that I bring it up here, so we can do it right from the start. But for me it's OK to do in separate PR, as long as it is slated for 0.20 I think we can simply use ``pandas.util.depr_module`` with specific exceptions listed, no? 

You basically deprecate them on first use, IOW simply importing them.

cc @gfyoung  @jreback: we had a similar issue with CParserError, and unfortunately, I don't think my depr_module applies in either case because it doesn't deprecate a class. @gfyoung how so? ``CParserError`` a class. In fact I would assert it doesn't matter *what* it deprecates, all it cares about is getting a name from a namespace. @jreback : But you can't really deprecate `KeyError` in this case, so I'm actually not sure what you're trying to achieve with `depr_module` in the first place. @gfyoung pls read the issue. I am going to deprecate the exceptions in pandas.core.common and move them to pandas.api.exceptions. @jreback : That's not in the original issue IINM, but in case, sure that should work what you're describing then. @Dr-Irv can you fix up and rebase. @jreback Last commit is the rebase and fixes the conflicting file, so not sure what to do next @Dr-Irv Can you just rebase? Then it should be good to merge @jorisvandenbossche I think my last commit includes the rebase and error message change. @Dr-Irv As you can see in the github interface, this cannot be merged due to conflicts (but it is possible this was only introduced since your last commit). @jorisvandenbossche I'm confused.  I can't find the conflicts it is reporting.  I did the following:
```
git checkout master
git pull
git checkout <branch>
git merge master
```
git reported that everything was up to date.  So there were no conflicts reported.  I'm not sure what to do. @Dr-Irv depending on your settings, I think `git pull` will fetch your latest 'origin' (your fork), where you want to fetch the latest upstream. 
What I typically do is

```
git fetch upstream
git checkout <branch>
git rebase upstream/master
```

(but the last line can also be `git merge upstream/master` if you want, that doesn't matter too much) @Dr-Irv There are still some linting errors (hence the failing travis, see at the bottom of this log: https://travis-ci.org/pandas-dev/pandas/jobs/182331460):

```
pandas/core/common.py:108:1: W293 blank line contains whitespace
pandas/core/common.py:111:1: E303 too many blank lines (3)
pandas/core/indexing.py:1817:80: E501 line too long (81 > 79 characters)
pandas/core/indexing.py:1818:80: E501 line too long (82 > 79 characters)
pandas/tests/indexing/test_indexing.py:3487:80: E501 line too long (80 > 79 characters)
``` @jorisvandenbossche I've now fixed those.  For some reason flake8 --diff didn't pick up those errors. @jorisvandenbossche So I resubmitted, but now the appveyor is failing, but looking at the logs, I can't figure out why. Don't worry about appveyor, it's not related.

Merging, thanks a lot!