Document all required opcode arguments before optional arguments

This patch does not change any content in the instruction
documentation.  It only shifts around one argument description so that
the descriptions for required arguments come first.
Allow setting a Scene’s background image within the constructor

Currently the only way to set the background for a scene is to call
the setBackground() method after creating the scene.  This can appear
counter-intuitive to some people because in similar situations, such
as when creating characters, that information comes first as part of
the new() method call.

If we change the ‘background’ property for Scene objects into a string
then it becomes possible to set that property within the constructor,
allowing for scripts such as:

    START = LNVL.Scene:new{
        background = "Nice-Pretty-Background.jpg",
        "Then the dialog begins",
    }

We already have a way to load scene images given a filepath: we can
simply call setBackground() within the constructor if the script
author provides the ‘background’ property.
Remove an erroneous call to table.remove() from the Scene constructor

The second argument we give to table.remove() is incorrect.  It should
be a numeric index, not a string like we use.  But the reality is that
we do not need to call table.remove() at all.  Leaving any property
definitions inside of the ‘properties’ list will not mess up opcode
generation later when treating ‘properties’ as an array of content.
That is because when creating content we go through only the numeric
indices of ‘properties’, and that will ignore any named property
assignments automatically.
Give an example of defining a scene background in the constructor
Give examples of defining other scene colors in the constructor
Document the easier way to set scene backgrounds in the Howto

It is more convenient and readable for script authors to define scene
background colors and images at the top of Scene:new().  We need to
change the Howto document to reflect this capability.
Document the new ‘set-scene-image’ opcode

We will use this opcode as part of a new function allowing us to
change the scene background images in the middle of scenes.
Add Scene.changeBackgroundTo() and the ‘set-scene-image’ opcode

This patch will implement the ‘set-scene-image’ opcode and provide a
function we can use in scenes to dynamically change the background
image: changeBackgroundTo().  The function is inefficient because it
will create new Image objects every time we process it, but this
provides only the essential code for an implementation.  If we need to
cache those images for optimization we will revisit this.
Add an example script to test Scene.changeBackgroundTo()

This script will crash the engine because the resulting ‘set-image’
instruction cannot change the scene’s background.  This happens
because the ‘target’ property of the original ‘set-scene-image’ opcode
does not point to the Scene object to affect.
Fix bug where ‘set-image’ crashes when changing scene backgrounds

The instruction ‘set-image’ does not have access to an LNVL.Scene
object to modify because the ‘set-scene-image’ opcode, which generates
the instruction, does not have access to that object either.  The
problem is that we create and process the opcode before construction
of the Scene is complete.  It is not possible to give the Scene object
to the opcode processor at that time.  And we cannot delay the call to
the opcode processor either.

To get around this conundrum we modify the processor for
‘set-scene-image’ so that it passes information to ‘set-image’ to
inform it that we are modifying an LNVL.Scene object.  By the time we
actually execute the ‘set-image’ instruction we do have access to the
correct Scene object; it will be the ‘arguments.scene’ property within
that instruction code.  That instruction always works by modifying the
‘target’ property, changing one if its images to the new image.  The
opcodes which create ‘set-image’ instructions are responsible for
preparing that target.  Since ‘set-scene-image’ cannot assign the
target, i.e. the then-uncreated Scene object, we delay assignment of
the target until we execute the ‘set-image’ instruction itself.

This patch will also update the instruction documentation with a note
about where to look in the source code for details on this delayed
assignment and why we do it.
Merge branch 'changing-scene-backgrounds'

* changing-scene-backgrounds:
  Fix bug where ‘set-image’ crashes when changing scene backgrounds
  Add an example script to test Scene.changeBackgroundTo()
  Add Scene.changeBackgroundTo() and the ‘set-scene-image’ opcode
  Document the new ‘set-scene-image’ opcode
  Document the easier way to set scene backgrounds in the Howto
  Give examples of defining other scene colors in the constructor
  Give an example of defining a scene background in the constructor
  Remove an erroneous call to table.remove() from the Scene constructor
  Allow setting a Scene’s background image within the constructor
Add a ‘name’ property to LNVL.Scene objects

This will allow us to give each scene a name inside of test scripts to
help with debugging, as will be able to print those names to screen.
Later this may also be useful in general for script authors, e.g. to
reference other scenes or show title-bars.
Support tostring() on LNVL.Scene objects for better debugging
Show the name of scene’s when running in debugging mode
Add a name to a scene in one example script for testing

This will let us see that the tostring() output for LNVL.Scene objects
is what we expect: the name of the scene if given.  We will see that
output automatically if we enable debugging mode when running this
example script.
Merge branch 'scene-names'

* scene-names:
  Add a name to a scene in one example script for testing
  Show the name of scene’s when running in debugging mode
  Support tostring() on LNVL.Scene objects for better debugging
  Add a ‘name’ property to LNVL.Scene objects
Prevent the scene opcode index from going out-of-bounds

The methods Scene:moveForward() and Scene:moveBack() do not place any
limits on incrementing and decrementing the opcode index.  Since we
call those based on user input it is possible for the user to move far
out of bounds of the actual indicies for the opcode list.  This will
not crash the game because access to the opcode list is always forced
to be within bounds, but that does not prevent the index we keep track
of from going outside of those bounds.  This patch will fix that
problem so that users cannot go too far forward or back in scenes.