TYP:  ExtensionArray delete() and searchsorted()
Additional typing for `ExtensionArray` `delete()` and `searchsorted()`

> Thanks @Dr-Irv . now that the EA methods are being annotated individually, it may make sense to add the annotations to all EA classes for that method to ensure consistency. (e.g. SparseArray looks iffy `def searchsorted(self, v, side="left", sorter=None):`

Next commit does this. Had to create some types to support the bridge from our `searchsorted` to numpy `searchsorted`.  Hope this works for you! @simonjayhawkins  @jbrockmendel pushed changes 5 days ago, so looking forward to a new review. all the `Literal["left", "right"]` changes look good.  the NumpySorter is fine AFAIK.  the value arg in searchsorted is pretty nasty though; can we live without it for the time being? > all the `Literal["left", "right"]` changes look good. the NumpySorter is fine AFAIK. the value arg in searchsorted is pretty nasty though; can we live without it for the time being?

I think we should go ahead as I proposed it.  The issue with `value` is that `ExtensionArray` has to support any type for a singleton, so it takes `object`.  Therefore the subtypes have to take any type, and ideally they should raise if the type is incompatible. This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. @jbrockmendel Awaiting your response for 6 weeks to my last response here:  https://github.com/pandas-dev/pandas/pull/41513#issuecomment-851580982
 > The issue with value is that ExtensionArray has to support any type for a singleton, so it takes object.

You explained [here](https://github.com/pandas-dev/pandas/pull/41513#discussion_r644726564) why you are using `object` instead of `Any`.  With `object`, the checker treats it as if that argument were not annotated (because everything matches), while with `Any` the checker skips the method completely.  Do I have that right? 

> Therefore the subtypes have to take any type, and ideally they should raise if the type is incompatible.

> The full signature has to accept the same type as the parent, and can widen that argument type, but not narrow it

IIUC "has to" here is in order to satisfy Liskov.  Is that right?  Liskov is nice, but in this context it is conflicting with _accuracy_.  e.g. in the PeriodArray case it is inaccurately suggesting that it will accept a timedelta.  If we have to choose between Liskov and accuracy, my inclination is to choose accuracy.  And if I'm right above that putting "object" is equivalent to leaving it unannotated, then this is introducing inaccuracy with _no_ upside AFAICT.

That said, this is not a hill I want to die on.  I'll defer to @simonjayhawkins  pinging @simonjayhawkins  @Dr-Irv this looks pretty good to me, can you rebase and hopefully @simonjayhawkins can have a look weekly ping @simonjayhawkins

 @simonjayhawkins Have just made a bunch of changes to use more numpy types in arguments and return types for `searchsorted`.

One odd thing was that I put the overloads for `searchsorted` that numpy uses only in `pandas/core/indexes/extension.py`.  Alternatively, I could put this everywhere, BUT as you'll see in the comments in that file, it requires a `type: ignore` statement, which is also present in the `mypy` definition of `searchsorted()` in `numpy/__init__.pyi`.  

I could put the same overloads throughout the code, but it would require the `type: ignore` messages in every place.  Let me know which you prefer.   biweekly ping @simonjayhawkins  @Dr-Irv ok if you can merge master and make sure still passing (i think it was last) time, will merge these. @jreback all green except for a Windows timeout on one of the tests thanks @Dr-Irv followup to consolidate any fixtures created here in other PRs