Encapsulate scrolling logic in a single `Scroll` (i.e. scrollable container) widget

[mitchmindtree]

Right now, scrolling logic is baked into conrod itself as a special case. This is slightly unfortunate, as it would be nice to be able to treat scrollbars and scrollable containers just as any other widget is treated. Ideally, we'd have a single Scroll widget, which is able to crop and scroll its children widgets. This would allow us to remove the need for tracking Scrollbars specially within the graph (and in turn allow us to remove the depth_order::Visitable type). We could also remove all the scroll logic that is currently nested within the widget::set_widget function.

There are a few reasons why scroll logic is baked into conrod itself right now:

1. Scissor / Cropping: right now there is no way for a widget to "crop" its children directly - there is a special case for scrollable widgets. It should be possible for us to make it so that widgets can simply call a method like .crop_kids, so this point shouldn't hold us back.
2. Applying xy offset to child widgets: there is currently no way for a parent to offset its children widgets (or for a widget to affect the co-ordinates of other widget whatsoever). Normally I think it can be a little dangerous to allow widgets to "mutate" other widgets, however I think it should be reasonable for us to add a method which would allow for a parent to offset its children widgets. I.e. .offset_kids.
3. Calculating the bounding box of all children in order to calculate the scrollable range: this should now be possible to do from within a widget, as these algorithms are exposed publicly from the graph::algo module.
4. "Draining" scroll events: This currently isn't implemented as it stands, but it is unclear how we would implement this in a custom widget. Basically; remaining scroll that is not used by a child scrollable container should roll over to the parent scrollable widget. Perhaps we could provide a method ui.drain_scroll(xy) -> Option<Point> which would allow for a widget to "drain" a certain amount of scroll from the Ui's stored Scroll events? Will have to think about this some more.

I think I'll avoid updating the scroll logic in #703 in favour of including this widget in a follow up PR.