Remove `Remedy::Partial` subclasses

[jcraigk]

The following subclasses contain no logic and seem to exist for naming semantics only:

Remedy::Content
Remedy::Header
Remedy::Footer

These should be removed and instead, Remedy::Partial should be supplied by the lib and the examples should reference only it. Currently, the README and menu example mentions Remedy::Partial in a comment and one must go digging to find out that all three of the above classes implement no behavior. These might be better left to the end user to implement if they so choose.

Design opinion: taking this concept a step further, the Remedy::View class could be made more useful by generalizing it into a collection of Partials rather than the semantic collection it is constrained to now: body, header, footer.

[acook]

Just to drop in my thoughts on the second idea in this:

While a generic View that just compiles every Partial handed to it could be useful too, the goal was to have a variety of layouts where something in the header slot would stick to the top of the layout and a footer would stick to the bottom, and then there would be various other ways to split the layout like Vim and Tmux do.

There is code in View and Viewport that needs to be split out into Layout to support this use case.

Simple
|-----------|
| header    |
|-----------|
|           |
| content   |
|           |
|-----------|
| footer    |
|-----------|


Horizontal Split
|-----------|
| header    |
|-----------|
|           |
| content 1 |
|           |
|-----------|
|           |
| content 2 |
|           |
|-----------|
| footer    |
|-----------|

Vertical Split
|-----------|
| header    |
|-----------|
| con | con |
| ten | ten |
| t 1 | t 2 |
|-----------|
| footer    |
|-----------|

Where things get fun is that each Layout has a compatible interface with Partial and can be dropped in. Nested Layouts!

I just haven't had a driving need to do so yet, so haven't built it out.