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

Wasn't sure where to add the whatsnew entry so left it out for now. Grateful for any advice. This PR supercedes #29248 which was a messy attempt at creating full HTML functionality for the Series class by creating a new HTMLColumnFormatter class and changing SeriesFormatter. This PR is much smaller in scope and hopefully easier to debug/merge/maintain. The scope can be expanded later to give full to_html functionality. The HTML rendering looks just like that proposed in #29248:

![series1a](https://user-images.githubusercontent.com/1134151/67718435-a7c4a000-f9c7-11e9-8a46-a6447563b688.png)

however rather than doing this via an independent formatter, it just uses DataFrame.to_html without any header or footer information, and then inserts a new footer into the HTML. Hello @big-o! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:













There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2019-12-29 22:58:31 UTC @WillAyd are you happy with the changes? I think everything is in place now but please let me know if any further work is needed. I made an assumption about where the What's new entry needs to go, let me know if this is wrong. Are you happy with everything in this PR now @willayd @simonjayhawkins? I noticed that some of the regression tests are failing again but I'm confident this isn't due to any of this work: Everything was passing then I had to merge in some other updates due to a clash when I updated the whatsnew RST with a new entry for my change. It looks like all the issues that are failing are from other tickets that are being worked on.

All the actual code changes are in https://github.com/pandas-dev/pandas/pull/29383/commits/4d40bb6e869e4e9f97452b327453fd8b60fbbf71, which passes all regression tests. This is exactly what I did originally, minus the base class (#29248), but it @WillAyd asked for it to be replaced with this PR because they preferred a smaller change, which could be expanded on in future.

This PR is small and contained and would be easy to replace with a SeriesFormatter in the future. Making a SeriesFormatter with a common Base class to DataFrameFormatter is a lot of work, unless you're happy to have a lot of repeated code. This is why the original PR was rejected.

If you now want a series formatter, please take a look at #29248 and decide if you want to accept that instead. If you want a more complete implementation with a shared base class then this is a large task that I wouldn't have time for right now.

Please have a think and maybe discuss it with @WillAyd and then let me know how you want to proceed.

I'd ask you to reconsider this PR though - it leaves a small footprint on the project, is well tested and will be easy to remove when you have a more complete solution. A complete solution will probably take a long time to implement and you'll be without the feature for a long time. @WillAyd @jreback have you had any thoughts on how you'd like to take this PR forward? Keen to get this feature into pandas but at the moment I've got some conflicting guidance on how to progress. If you need to think more about how you'd like to take this forward that's fine, but it would be good to know if it can be implemented in its current shape or if it needs to be reworked again first. cc @jorisvandenbossche if you'd look here can you merge master and we'll look again > can you merge master and we'll look again

Done - I'm assuming you don't want any changes other than those necessary for the merge right now as I haven't heard anything regarding which approach to take. Please let me know if you want any further changes and what they should be if so. @big-o any chance you took a look at the design suggested by @jreback to have a GenericFormatter that DataFrameFormatter and SeriesFormatter would both inherit from? The latter are already defined in format.py so wondering if you have ideas on how to better construct a class hierarchy for them I looked into it originally, as that was my plan too. It's quite a complicated class for someone who is new to the codebase so I think it would take me quite a while to unpick. That's why I originally went for a slightly messy compromise with #29248, which was rejected by @WillAyd who suggested the approach in this PR.

I know this PR isn't perfect but it gets a new feature in with almost no changes to the original codebase, and only small additions that can be easily removed and replaced with a proper `SeriesFormatter` at a later date.

I'd be happy to write the `SeriesFormatter`, but it will take some time for me to implement - as well as the time needed to figure it all out and make the code changes necessary, I also need to fit this work around my job. In the meantime people could be making use of the feature via this PR without the rest of the codebase being affected, so would it be possible to go along with the original decision of taking this more limited approach, giving a workable feature for people to use until the more complete solution comes along? @big-o looks like the desired design is to have the GenericFormatter as a base which SeriesFormatter / DataFrameFormatter inherit from - is that something you are still looking at? Closing as I think stale but ping if you'd like to give the suggested design approach a shot Sorry for the slow response; my time has been limited lately. I need to prioritize other things right now but if I get time to look into it again I'll leave a comment here.