Update the constructor calls in the ‘04’ example script

The script continues to use the old constructors, not the new()
methods that have been part of LNVL for quite a while now.  This patch
also changes the calls to the constructor for LNVL.Menu even though
that class does not yet exist.  We will use new() for its constructor
when we do write it, for consistency with the rest of the classes, so
we can go ahead and change the calls in the example.
Create the LNVL.Menu class

Currently it does nothing but accept a table of properties in the
constructor, as with most other classes.  Although we define no
properties or provide any other methods.
Load the LNVL.Menu class as part of the engine

With this patch we can run the ‘04’ example script, although it does
not show any menus since that functionality does not yet exist.
Create the LNVL.MenuChoice class

It will be useful in the code to have a way to differentiate tables
representing menu choices from other tables.  This class will serve
that purpose.  It will also provide us a way to more conveniently
access data in menu choices via named properties, as opposed to
relying on table indices which could change in the future.
Load LNVL.MenuChoice inside of the LNVL.Menu code
Clarify why we do not need to load LNVL.MenuChoice in ‘LNVL.lua’
Assert that new MenuChoice objects have the correct properties
Store choices for a menu when calling the LNVL.Menu constructor

This patch converts the arguments for the constructor into
LNVL.MenuChoice objects.  This code causes the ‘04’ example script to
break since that script uses strings for the so-called ‘action’
parameter of each choice, while the implementation demands that each
‘action’ be a function.  Later we will provide logic that turns those
strings, which name LNVL.Scene objects, into functions that will cause
the flow of a story to jump to those scenes.
Provide tostring() support for MenuChoice objects
Document in code possible return values for ‘MenuChoice.action()’

The initial design of the property—a function—was that it would never
return anything.  However, it is useful in retrospect to allow the
action function for a menu choice to potentially return one or more
LNVL.Opcode objects.  This will make it possible for menus to affect
scenes by returning existing opcodes for the scene to process instead
of having to re-implement the behavior of those opcodes.
Allow scene names as strings for the actions of menu choices

We require the ‘action’ property of a MenuChoice object to be a
function which may return opcodes.  However, for convenience we allow
the values for actions in scripts to be strings that represent the
names of scenes.  The implied action is to switch to the named scene
if the player chooses that item from the menu.  For example, we allow
menu definitions like this in scenes:

    LNVL.Menu:new{
        {"Enter", "ENTER_SCENE"},
        {"Don't Enter", "LEAVE_SCENE"},
    }

LNVL should switch to one of the two scenes, ‘ENTER_SCENE’ or
‘LEAVE_SCENE’, depending on what the player chooses.  In this case we
assume those strings are the names of LNVL.Scene objects that the game
author creates somewhere.

This patch makes the LNVL.Menu constructor aware of these types of
strings.  When it sees a string it will first convert that to an
anonymous function that returns a ‘change-scene’ opcode.  Then the
MenuChoice constructor will not stop the program with an error since
we will always correctly give it a function for the ‘action’
property.

We can now run the ‘04’ example script again with this patch in place,
although the scene changes do not work because we have not made LNVL
aware of the opcodes that menu choices can create.
Use a clamped array for the ‘LNVL.Menu.choices’ property

This will prevent accidental out-of-bounds errors when accessing the
choices in a menu, similar to what we do for the contents in scenes.
Add the ‘currentChoiceIndex’ property to the Menu class

We will need a way for other parts of the engine to easily determine
what choice a player has selected.  This index provides that
information by acting as an index for the ‘Menu.choices’ array.
Remove a currently unused for-loop from the LNVL.Menu constructor

Initially I wrote the property assigning loop that we use throughout
other classes.  However, we do not need this behavior for Menu objects
right now.  So let’s remove dead code early before it sticks.
Add methods for cycling through menu choices

This patch provides two methods to move forward and back through the
available choices in a Menu object, providing other parts of the
engine a simple interface for cycling through those choices in the
same way we move through content in Scene objects (using methods with
the same names).
Merge branch 'basic-menu-class'

* basic-menu-class:
  Add methods for cycling through menu choices
  Remove a currently unused for-loop from the LNVL.Menu constructor
  Add the ‘currentChoiceIndex’ property to the Menu class
  Use a clamped array for the ‘LNVL.Menu.choices’ property
  Allow scene names as strings for the actions of menu choices
  Document in code possible return values for ‘MenuChoice.action()’
  Provide tostring() support for MenuChoice objects
  Store choices for a menu when calling the LNVL.Menu constructor
  Assert that new MenuChoice objects have the correct properties
  Clarify why we do not need to load LNVL.MenuChoice in ‘LNVL.lua’
  Load LNVL.MenuChoice inside of the LNVL.Menu code
  Create the LNVL.MenuChoice class
  Load the LNVL.Menu class as part of the engine
  Create the LNVL.Menu class
  Update the constructor calls in the ‘04’ example script