Menu architecture, part two

[Twisol]

Hello again! This is a fairly large pull request, but there's some exciting stuff going on here (IMHO). :smiley: I'll break it down below.

Major changes

• I removed the MenuScreen class. MenuScreen embodied a single kind of menu, but as happened in LevelSelectScreen and others, some of the fundamental behavior of MenuScreen had to be overridden. That's a sure sign that inheritance isn't the way to go.
• I added two template classes: MenuTemplate and DetailsTemplate. MenuTemplate more or less does what MenuScreen did, but additionally decoupled from the GameScreen machinery. DetailsTemplate provides a unified way of creating screens with textual information and some navigational buttons.
• I overhauled the way that transitions and animations are applied. This patch includes a GraphicsCursor representing the active effects to be applied to anything being drawn. To make the effects system extensible and generalizable, an IEffect interface has been introduced.
• The existing pulsate, transition, and fade effects have been factored out into new IEffect implementations. More effects can be defined as desired.

  Issues

• Text in the DetailsTemplate will be centered, rather than left-justified as it was before. This doesn't appear to be a breaking issue, as all affected screens look fine either way. However, we may want to add an ljust/center/rjust property to the menu item classes so that this may be configured.
• There's now a good deal of repetition in each of the Screen classes due to the removal of MenuScreen. I'm hesitant to re-introduce a shared superclass, and I'm sure there's a more compositional way to approach this, but I haven't spent much time on the problem.
• The Scaling and Offset properties of the GraphicsCursor don't interact very well. (Try setting Scaling to 0.5f in MenuTemplate.Draw.) A matrix-based approach to such affine transformations might be best.

  Future work

• Currently, each template deals directly with the effects of its children. In addition, effects are instantiated every frame (in Draw), which is not especially efficient. These effects should be factored out and provided by an external caller.
• Effects can easily be chained together. An EffectGroup should be created that implements IEffect, combining multiple effects together to produce a single effect. This is useful because every consumer of IEffect need only deal with a single IEffect. No template or screen needs to explicitly deal with lists of effects.
  • Implemented in 62f3438.
• A StatefulEffect class may be desirable, to switch between effects based on the state of an object. This would unify, for example, how screen transitions and pulsating buttons are animated.
  • Implemented (as EffectGuard) in 79b2ffc.

[Twisol]

I added the aforementioned EffectGroup in 62f3438, and EffectGuard in 79b2ffc. Neither is currently in use, but I think they'll end up being handy later.