COMPAT: unique() should preserve the dtype of the input
The behavior of `pd.unique()` is surprising, because -- unlike `np.unique()` -- the result does not have the same `dtype` as the input:

```python
In [1]: pd.Series([1,2,3], dtype=np.uint8).unique()
Out[1]: array([1, 2, 3], dtype=uint64)
```

This PR just casts the output array to match the input dtype.  Supercedes #27869.

**Update:** Augmented the tests to cover narrow dtypes.

~I added a new assertion in `test_value_counts_unique_nunique()`, but it may not be sufficient.  From what I can see, there isn't good coverage of `Series` whose *data* is not `int`/`float`/ etc.  There is only good coverage of various *index* types. Any advice concerning test coverage?~

- [x] closes #27869
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

@jreback I added the requested test cases and rebased.  The CI is passing now.

BTW, I had a problem with an unrelated test.  It was [expected to fail][1], but in this PR it magically started passing -- under Python 3.5 only.  Probably somehow related to dict ordering.  Anyway, I "fixed" the issue by [simply permitting the test to `xpass` under Python 3.5.][2]

FWIW, I'm not the only one who ran into that `xfail` problem. It was also encountered recently in PR #27762.

[1]: https://github.com/pandas-dev/pandas/blob/5de4e55d60bf8487a2ce64a440b6d5d92345a4bc/pandas/tests/series/test_analytics.py#L1492

[2]: https://github.com/pandas-dev/pandas/pull/27874/files#diff-dc347bc3d0448ea297bed67dc7ff3437R1494 can you merge master; update the release note to 1.0, will have a look after Sorry I haven't had time to look at this.  I'll try to get to it next week. @stuarteberg looked reasonable, can you merge master and move the note to 1.0.0 @jreback 

>looked reasonable, can you merge master and move the note to 1.0.0

Done.  Sorry I haven't cleaned up the tests yet.  If its sufficient as-is, great.  If not, let me know. thanks @stuarteberg this looks great! Can you create an issue to parameterize test_base (where indicated)? A PR would be most appreciated for that as well (if you can). this did not have any issue (other than the PR itself) associated? can you do a quick search to see if this solves any open issues? >this did not have any issue (other than the PR itself) associated?
>can you do a quick search to see if this solves any open issues?

OK, I couldn't find an issue for this in particular, but I just found #22824, which has a much broader scope.  It does mention the return type issue:

>- [ ] Change return type for [Series/Index].unique to be same as caller (deprecation cycle by introducing raw=None which at first defaults to True?)

But since this PR doesn't resolve everything mentioned in that issue, it should remain open.  But I made a comment there referencing this PR.

>Can you create an issue to parameterize test_base (where indicated)?

OK, I have an issue draft ready to go (pasted into the details section below), but github noticed that #23877 is similar.  Is that already sufficient, or would you like me to open the new issue anyway?

<details>

<summary>Issue draft regarding test_base</summary>

The tests in `tests/test_base.py` exercise the behavior of both Series and Indexes of various dtypes, but without using the standard `pytest` mechanisms for parameterization.  In particular, the [setup of the `Ops` base class][1] should be cleaned up (or removed) in favor of proper pytest fixtures.

[1]: https://github.com/pandas-dev/pandas/blob/a1dba2c6d6140896cdb23d9c9f094d8c71094ccf/pandas/tests/test_base.py#L167

FWIW, this was [noticed][2] while reviewing #27874, so @jreback [requested][3] this issue to be opened.

[2]: https://github.com/pandas-dev/pandas/pull/27874#discussion_r314311204
[3]: https://github.com/pandas-dev/pandas/pull/27874#issuecomment-538802943

</details> @stuarteberg no #23877 is ok  thanks @stuarteberg 