Document how ‘handlers’ can be plain functions, not always coroutines

We open up the possibility for handlers to be functions because it
will allow us to provide hooks into LNVL for situations where a
coroutine would be unnecessary, situations where the developer would
not want the game logic to continue until the handler finishes,
e.g. drawing a character to screen before presenting his or her
dialog in a scene.  We can do this with coroutines but to do so is to
simply call functions in a complicated, verbose way for no gain.
Create and document Settings.Handlers.Drawable()

We will use this function as a hook to allow games to render images to
screen in a way they find most fitting, if necessary, as the comments
for the code attempts to explain at length.

Note that this patch does not work.  It assigns the handler a value
that does not exist, i.e. ‘LNVL.Drawable.DefaultHandler’.
Make Settings.Handlers.Drawable a table with two hooks

We need to allow handlers for two Drawable methods:

1. draw()
2. setPosition()

The original design accounted only for the first.  This patch
redefines the Drawable handlers as a table of two functions, one for
each method.  It makes appropriate changes to the documentation to
explain the changes to the API and the arguments those functions
receive.

This patch also addresses a problem posed by the previous commit: how
do we assign a default handler when LNVL loads the Settings module so
early?  We cannot assign any functions from the Drawable module
because we do not have access to it when loading Settings, because we
load the former much later.  So this patch documents the approach we
will take to get around that: assigning temporary ‘nil’ values that we
will change to actual default handlers elsewhere, with documentation
pointing out where other developers can find those defaults.
Implement default functions for the Settings.Handlers.Drawable table

We use the existing Drawable:draw() and Drawable:setPosition() methods
as the default implementations for the two functions required to
satisfy the Settings.Handlers.Drawable table.  We slightly rewrite
those methods as slighty-renamed functions so that we can use the
actual method names as ways to invoke the handlers.  This extra level
of indirection makes it possible for games using LNVL to now customize
how they render Drawable objects to screen.
Replace ‘gamers’ with ‘game developers’ in documentation

Developers are the target audience for the documentation describing
the opcode and instruction parts of the engine, not gamers.
Fix a Markdown markup error in the ‘Howto’ documentation

It is not really an error, but parentheses right next to bold
markup—two asterisks—does not play well with some Markdown parsers.
Restrict the list of valid positions to the Positions module

This patch makes the previously publicly accessible
‘Position.ValidPositions’ table into a local table whose scope does
not extend beyond the Positions module.  We want to provide hooks an
openings for developers to modify LNVL as needed without having to dig
into the LNVL code itself.  But we should have the attitude that
things must be private first, only made public and modifiable if
necessary for games using LNVL.  This will help avoid situations where
a game may rely on a feature that we later want to make private but no
longer can because something already relies on it.

TL;DR Encapsulation
Implement Drawable:setLocation()

This provides the engine and games a way to forcibly set the location
of a Drawable object on screen.  This patch also clears up some
documentation about the acceptable values for the ‘location’ property.
And it clarifies the distinction in how the engine uses the terms
‘position’ and ‘location’ with regard to Drawables.
Extract the logic for Opcode.__tostring() into a separate function

This takes all of the code for that metatable function and moves it
into a function local to the Opcode module: formatOpcode().  Now
converting an Opcode into a string involves calling that function.
The motivation for this separation is so that I can occasionally (and
probably temporarily) add extra debugging information strictly inside
the tostring() function.
Add the ‘set-position’ instruction to fix the ‘move-character’ opcode

It turns out the ‘move-character’ opcode has not worked properly for a
long time—which unfortunately I failed to notice.

The opcode would change the ‘position’ property of a Character
object but the result is that we would immediately render that
character in the position of the final ‘move-character’ opcode in the
scene.  That is because we process all opcodes before executing any
instructions, and instructions are what render characters.  Therefore
all of the modifications to the ‘position’ property happen before any
instruction execution and thus any rendering.

The seemingly obvious solution is to defer the change of the
‘position’ property until the instruction execution cycle.  This patch
does exactly by introducing the new ‘set-position’ instruction.  We
change the ‘move-character’ opcode so that it informs the instruction
what object it should affect, i.e. which object has the ‘position’
property it should change.

With this patch in place example scripts like ‘07’ work as intended.
Trying to back up through all of ‘07’ does not completely work, as in
returning the character to its original starting position.  But for
now we can accept scenes not being able to perfectly deal with moving
backwards through content that changes character positions.
Merge branch 'ejmr/drawable-handlers'

* ejmr/drawable-handlers:
  Add the ‘set-position’ instruction to fix the ‘move-character’ opcode
  Extract the logic for Opcode.__tostring() into a separate function
  Implement Drawable:setLocation()
  Restrict the list of valid positions to the Positions module
  Fix a Markdown markup error in the ‘Howto’ documentation
  Replace ‘gamers’ with ‘game developers’ in documentation
  Implement default functions for the Settings.Handlers.Drawable table
  Make Settings.Handlers.Drawable a table with two hooks
  Create and document Settings.Handlers.Drawable()
  Document how ‘handlers’ can be plain functions, not always coroutines