WIP [DOC/EA]: developer docs for implementing Series.round/sum/etc in EA
This summarized my current understanding of how the dispatch of Series methods *should* work for EA (related https://github.com/pandas-dev/pandas/issues/26913, https://github.com/pandas-dev/pandas/issues/26730, and https://github.com/pandas-dev/pandas/issues/26835) and It also provides helpful warnings against  the several pitfalls I fell into while figuring things out. There are a lot more details involved then I foresaw.

The document is sloppy pseudo-sphinx for now (I haven't even compiled it yet), just to see if you agree with the content before spending the effort to polish it. I will, if/when the content represent a consensus instead of just my own take on the issue.

The description of how things work doesn't match the current state of the code right now, because there are a lot of little cleanups to be made in various functions:
- Getting rid of `com.values_for`
- Getting rid of `_values` and maybe even `_data` in some cases
- Getting rid of redundant calls to `np.asarray(self)` or `np.asarray(self._values)` and such.

but I don't think there's actually any radical change implied. It's just about making methods consistent in how they delegate to numpy, so that EA developers can count on predictable behavior and so reason about how the pandas, numpy, and their own classes interact. 

So I hope this will actually seem natural and undramatic, but I may have overlooked one or more vital issues.

One important realization I've come to is that the recent discussion regarding NEP18 was somewhat
of a red herring rabbit-hole. IMO, pandas should simply provide the explicit guarantee that some things go via `_reduce` (or a future [`__reduce_pandas__`]()https://github.com/pandas-dev/pandas/issues/26915), while the others go to `np.<func>(array)`, and that the return value type should be an ExtensionArray when applicable. How the EA author deals with numpy's dispatch logic is nothing we need or should want to to speak out on. That's between the EA author and numpy. 

Avoiding NEP18 altogether means that #26817, the `round()` PR, can be simplified to just a one line change to `Series.round`, and adding a new 4-line `round` method on `DecimalArray` as an example. 
This would be the typical change needed to support (and provde examples) for other Series methods which are currently out of alignment. So going down the NEP18 (as suggested to me) seems like it was a misstep IMO, now we know.

Possible Concerns for future (not covered in doc):
- How should we support EA for np operation which Series does not provide, like `ceil` (discussed in #26892). We may need to modify `Series.apply` with a special case for EA, so that `s.apply(np.floor)` works for EA. I'm not sure.
- What if future operations are added to the Series namespace? If we ever add a new Series method, which is not a reduction (going via `_reduce`), and is not a convenience around some
numpy function (so that the guarantee mentioned above doesn't hold), we will need to have a new
mechanism in order to allow EA to support it.  if this is a real concern, and there's no good answer, we might want to think about having a more general dispatching interface in place right now, instead of settling on the numpy dispatch guarantee mentioned, so as to be handle both existing and future operations.

As an imaginary example, if next year we add the  `Series.fnorb` method, which fnorbs a numeric array  using a new, cutting-edge, cython-optimized fnorbing algorithm, how do we then allow EA authors to provide an implementation for their own int ndarray backed EA? 

cc  @jorisvandenbossche, @TomAugspurger.