implement vertical slider orientation

[B-Reif]

This PR implements a vertical orientation for Slider. Closes #589.

What's new

• Sliders demo now includes a radio button toggle for orientation
• New enum SliderOrientation with variants Horizontal and Vertical
• New mutator function .orientation to set the slider orientation
• New constructor functions, new_vertical and from_get_set_vertical to instantiate with vertical orientation.
• Vertical Sliders use alternate keycodes for increment/decrement (up/down instead of right/left).

What's changed

• Replaces horizontal-specific Slider logic with some functions matching on orientation instead. Some functions and parameters are renamed (e.g. x_range -> position_range).
• Some helper functions are now methods on Slider which match on the Slider's orientation.

Alternatives

• If API breakage is ok, we could add an orientation argument to existing constructor functions (instead of creating new constructor functions).
• We could expose only the .orientation mutator function (instead of changing or creating constructor functions).
• We could expose a vertical slider as a different widget. The logic is similar enough that I think the sharing here is appropriate.

[emilk]

I've skimmed through it, and overall it looks good! Will review properly when I find the time.

[emilk]

This looks a bit bad to me. I guess most people who use a vertical slider won't want the label text (no shown above), but the slider value would be very nice to show, and should be below the vertical slider.

[B-Reif]

Ok, made review changes and moved the value below the slider. Also added a new method add_contents to invoke inside of either ui.horizontal or ui.vertical respectively.

This implementation will arrange the slider, value, and then label in a vertical layout. We could further group the value and label onto one horizontal line.

[B-Reif]

I'm having some issues with the keyboard step functionality of Slider, but I experience them on the current master branch also. These could probably be resolved in a separate PR.

[emilk]

The f32, usize etc are also possible line below belongs together with the i32/f64 switch above