BUG:  Fix series.round() handling of EA
- [x] closes #26730
- [x] tests added / passed
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry
- [ ] Happy with approach

Note that the change to a `np.round(self.array)` call was chosen so that
- it works for numeric ndarrays 
- it works for EA's which implements `__array__` and return a numeric ndarray
- once numpy 1.17 is out and NEP-18 support is enabled by default, it will enable
EA authors to implement round functionality via the `__array_function__` protocol.

**Update**: 

This has become a test case on supporting a wider range of numpy functions for EA. 
Here a some of the issues encounterd, several are indicative of the issues EA authors will encounter when trying to do the same:
1. Calling numpy function may require a roundtrip through an `object` dtype, so results need to be
cast to the extension type. Example: `np.repeat`
2. Converting EA to a numpy array, if using NEP-18, means inspecting all the arguments looking for EA passed in, once you find them you need to coerce them, they be an EA of a different class, so you only know about them what's available through the EA protocol. Example: `pd/np.concatenate`
3. ExtentionType discovery: discovering whether an EA has is essentially numeric, retrieving that representation, finding the best common dtype for mixed dtypes. Your EA may need to intelligently coerce an EA of another dtype. and cast back the result to the best dtype. Example: `pd/np.concatenate`
4. Once you use NEP-18, numpy ignores `__array__()` even if available, so there's no transparent casting to object.
5.`ExtensionArray` ABC doesn't offer a public API for requesting the backing numpy array of an EA, explicitly asking for numeric version (if applicable), or object dtype. [hgrecco/pint-pandas](https://github.com/hgrecco/pint-pandas) implements a [`_ndarray_values`](https://github.com/hgrecco/pint-pandas/blob/2cf891b63be778496e732f1ff9129eea6f38be73/pintpandas/pint_array.py#L51) method for `PintArray`, because you always need one (just as Series has `.values` and now `.array`), but it's not part of the EA base class and, for mixed-dtype cases, you need such a method when you dealing with a foreign EA.
5. The `Decimal` EA example defines a whole slew of synonyms for `self._data`, `data`, `_values`, `_items` for "pandas compatibility", these attributes have ill-defined or undefined semantics, leading to the same confusing situation () of `Series` having `.values` `_data` and ,`.get_values`, `.data`, and now `.array`. Seems like repeating old mistakes again.
6. If such aliases are **necessary** for pandas to recognize, they should defined and made part of the ABC.
7. aliases should not be attributes `self.foo=self._foo = values`, because then assigning to one does not update the other, and its not clear where the "actual" data is. Instead should use properties which lookup from the single, true, attribute which holds the data. I had a bug related to this because I set `_data` on a copy instead of calling a constructor. safety first.
8. another case: suppose you wish to convert the dtype of the EA's underlying numeric ndarray from float to int. there is no `transform`  like method provided for the user to do that without reaching in and touching private attributes of the EA. Example, a `PintArray` with units, which you want to `round()` and convert to internal dtype. The ExtensionType doesn't change, but the underlying numeric subtype does. For example `pint[grams] (with float64 magnitudes) -> pint[grams] (with int64 magnitudes) ` .

Update:
1. EA authors are forces to implement 3 (!) separate dispatch function to handle common functions. `__array_ufunc__` for ops `np.floor`, '__array_function__` for ops like `round`, and `_reduce` for ops like sum/min/max, which pandas doesn't call numpy fo (instead calling `pd.core.nanops`), and has incompatible signatures with. 