Show the focus and hover states in components

[Dawoodoz]

There are now state flags for direct and indirect hovering over components, which has both getters and state update notifications. There is however no integration with how components are rendered using the information, which needs to be done do that the interface gives instant feedback on which component would respond if clicked.

One can display hover using:

• More permutations of pre-generated images
  - Wasting memory exponentially
  - Limited to a single layer
• Scale a silhouette image to draw on top when needed
  + Memory efficient
  - Only glowing hover styles allowed
  - Slow to render
  - Complicated to generate non-standard formats from the MediaMachine
• Draw an alpha filtered image on top
  + Somewhat flexible in which styles to choose
  - Can get RGBA image from the MediaMachine
  - Even slower to render
• A single image that is regenerated when state changes a property used as input for the method, just like when it is resized
  + Uses less memory
  + Full control over the background
  + Simpler code by getting a reusable state bit mask from input arguments in the theme and assigning the state directly by asking the component when detecting the arguments
  + Can be scaled up to handle 288 permutations at no extra cost (enabled/disabled, locked/writable, pressed/lifted, selected/not, checked/not, direct/indirect/no focus, direct/indirect/no hover)
  + Flexibility to add any state for any component in the theme without changing code in the component

The menu expansion might also want to display that a menu is opened using something else than a hardcoded color change. An "enabled" property might be okay to implement using only color changes, because it is rarely used.

[Dawoodoz]

To generate all combinations without having to draw an exponential number of images by hand, the media machine needs conditional jumps to make some draw operations optional.

[Dawoodoz]

Menus now have focus and hover effects.
#94

[Dawoodoz]

If adding hover effects for buttons, it will look strange without reacting to leave events, because the cursor may go from hovering a button along the side to going outside, leaving the button in a hovering state when the mouse is outside. Implementing enter and leave events would however further complicate integration and testing on each platform where mouse input is used. Having enter and leave events optional would leave applications that depend on them broken. Maybe just implement leave without enter in the back-end and detect enter events automatically in DsrWindow on the first move event after leave.

[Dawoodoz]

Focus for components might also need events for getting and losing window focus. One would need to implement both focus events because a window can be activated without interacting with the canvas, but it could be entirely optional to implement by simply telling components not to show focus when not supported. When textboxes are used however, it is a helpful cue to know when you can type into something.