Stop flattening arrays of opcodes when constructing Scene objects

Currently when the engine sees an array of opcodes it flattens those
out into the list of opcodes for a given scene so that we end up with
a continuous array of opcodes to execute one-by-one.  This approach
causes problems because there are times when we need to execute
multiple opcodes at once, e.g. drawing a character’s avatar to screen
and printing dialog from that character simultaneously.  The first
step to supporting this is to stop flattening lists of opcodes.
Instead, if we receive a list of opcodes when building a scene we will
save that list as-is.  Later when executing the contents of that scene
we will treat lists of opcodes as groups to execute all together as if
they are one, single unit.

This will only be a first step though, and this change will break the
engine until we implement some additional measures.
Teach LNVL.Debug.printOpcodeTable() to handle groups of opcodes

Now that scene opcodes can contain nested lists of opcodes we need to
update the debugging output function to deal with that.  This will
show the groups of opcodes with labeled numbers to help keep track.
Stop Scene:drawCurrentContent() from crashing on groups of opcodes

This way the function will convert arrays of opcodes into multiple
instructions and execute each.
Implement a short-hand method for processing opcodes

By teaching Opcode objects how to invoke their own processor functions
on themselves we can improve the readability of code that needs to
deal with groups of opcodes, particularly code where the processing of
one opcode leads to the creation of multiple new opcodes.
Use Opcode:process() within Scene:createOpcodeFromContent()

This only cuts down one line of code but is a small improvement.
Draw characters on screen when they are speaking

This patch teaches the engine to (potentially) generate two opcodes
given a ‘say’ opcode:

1. draw-character
2. say

If a Character object is part of the arguments to the initial ‘say’
opcode then the result will be the two opcodes above.  This will
result in the engine later executing a ‘draw-image’ and ‘say’
instruction simultaneously, rendering the avatar of a character on
screen as that character is speaking.
Improve the variable names in Scene:createOpcodeFromContent()

Using ‘processed_opcode’ inside of the main for-loop is confusing
considering how we call the Opcode:process() method at the end.
The names in the loop make it read like we already processed the
opcode.
Process each individual ‘say’ opcode inside a ‘monologue’ opcode

By which we mean call Opcode:process() on each of the ‘say’ opcodes
that the ‘monologue’ opcode creates.  If we do not then the engine
will not draw the character giving the monologue on screen.
Do not draw a character in ‘say’ opcodes unless they have an image

If a ‘say’ opcode has an associated Character object then the engine
creates an additional ‘draw-character’ opcode so that the character
appears on screen along with the dialog.  This crashes the engine if
the Character object has no image to draw, i.e. the value of

    Character.images[Character.currentImage]

is nil.  So the processor for the ‘say’ opcode must check for this
before deciding whether or not to create a ‘draw-character’ opcode.
Allow for optionally flattening lists of opcodes

When a scene is converting its content into opcodes it will receive
one of two things for each chunk of content:

1. A single Opcode object.
2. A table of Opcode objects.

The default behavior in the second case is to insert that table
directly into the scene’s list of opcodes.  We do this under the
assumption that the engine should treat these opcodes as a group, a
single unit to later convert into instructions and execute.  This
behavior is a good default because it takes care of such situations as
drawing a character avatar on screen at the same time he/she is
speaking.

However, there are uncommon situations where we want the engine to
flatten a table of opcodes.  The largest current example is the
‘monologue’ opcode.  This opcode results in the creation of a number
of ‘draw-character’ and ‘say’ instructions, each pair grouped together
in a table.  We screw up the engine by using that table of tables
because LNVL treats the entire monologue as a group, executing all of
those sub-opcodes at once.  That means it prints every line of the
monolgue to the screen at the same time.

Whoops.

In the case of monolgues we actually want to flatten the resulting
table of opcodes out into individual opcodes (or tables) to insert
into the scene’s opcode table.  To make that possible we will
introduce an optional ‘__flatten’ table property which opcode
processors may set, indicating to the engine that it should flatten
out that table of opcodes appropriately.
Clarify one situation where we do not call Opcode:process()
Fix the bug of not properly processing lists of opcodes in scene’s

Commit 400ec11c (‘Allow for optionally flattening lists of opcodes’)
incorrectly removes the loop from the Scene:createOpcodeFromContent()
method which deals with lists of opcodes.  We need to reintroduce that
logic to fix the engine.  But this gives us a chance to tighten it up
a little because we do not need to recursively call the method.  All
we need to do in the loop is make sure each opcode calls its process()
method, then collect and return the results.
Clarify the meaning of ‘content’ in Scene:drawCurrentContent()
Remove unnecessary whitespace in file-header comments

These are accidents created when I changed part of my Lua-related
setup in Emacs, and I failed to catch the changes before committing
them.  This patch only affects whitespace in comments.  It contains no
changes to code or to the comments themselves.
Merge branch 'simultaneous-opcode-execution'

* simultaneous-opcode-execution:
  Remove unnecessary whitespace in file-header comments
  Clarify the meaning of ‘content’ in Scene:drawCurrentContent()
  Fix the bug of not properly processing lists of opcodes in scene’s
  Clarify one situation where we do not call Opcode:process()
  Allow for optionally flattening lists of opcodes
  Do not draw a character in ‘say’ opcodes unless they have an image
  Process each individual ‘say’ opcode inside a ‘monologue’ opcode
  Improve the variable names in Scene:createOpcodeFromContent()
  Draw characters on screen when they are speaking
  Use Opcode:process() within Scene:createOpcodeFromContent()
  Implement a short-hand method for processing opcodes
  Stop Scene:drawCurrentContent() from crashing on groups of opcodes
  Teach LNVL.Debug.printOpcodeTable() to handle groups of opcodes
  Stop flattening arrays of opcodes when constructing Scene objects