Add support for rotating Widgets.

[mitchmindtree]

It would be nice to support rotating arbitrary widgets. It would make it easier to implement things like circular context menus (popular in a lot of games) and vertical text (useful for plots).

piston-graphics does this using the its transform matrix, however as we are a UI library there are some more considerations:

• How will picking widgets with the mouse work?
• Should we automatically transform input events relative to the rotation of the widget? E.g. if a NumberDialer is rotated 90º, should it receive pre-rotated mouse events when calling ui.widget_input(id)? Or should it be up to the widget designer to consider the rotation, maybe by calling something like ui.widget_input(id).rotated().
• How will the graph::algo::kids_bounding_box function work (necessary for scrolling)? Perhaps rather than doing a min_max on the sides of the rectangles along both access, we do the min_max on the corners instead?
• What should the semantics be when rotating a widget that then crops its children? Currently we do this using a scissor, however I'm guessing we'd need to use a stencil instead if we were to support rotations?

These questions are what I could think of off the top of my head, however we should do a more thorough review of conrod and make an effort to find all the places where we make the assumption that no rotations occur, so we can create a more detailed list of the areas we need to address. It'd be nice if we could try to answer these questions before diving in to implementation.

I think the simplest way to store these rotations would be by adding a radians fields to the widget graph::Container, describing the rotation of the widget relative to its immediate parent. The total rotation of a widget could be determined by summing its radians with the radians of all its parent widgets. #836 is related.

[tl8roy]

A few Friday afternoon thoughts:

Probably one of the things that need to be added is arbitrary button shapes. This would probably solve the first issue.

Input events should be rotated the same as the widget. Anything else would be confusing. That said, there may be a alternate setting that changes this relationship.

The bounding box should be defined by the lowest point and the highest point. I think this would be the corners.

I think adding a Rotational trait similar to the ```Positional`` trait is logical.

[patrickpissurno]

Any progress on this?

[pedrocr]

Being able to do this at least for primitive widgets would be very useful. Being able to rotate an image for example has a lot of use cases. Would starting with primitive help or have the same issues with events and sizing?