Revert "Fixed pathfinding failure on straight lines"

This reverts commit d7ce6ef322da6039218857ff6019a659e43bb746.
Fixed pathfinding failure on straight lines (take 2)

This fixes a bug that has been reported by several forum folks:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48529

Bug tracker here:
http://www.adventuregamestudio.co.uk/forums/index.php?issue=418.0

The pathfinding algorithm often fails to find a path when navigating in
a straight line from the player's current location. My thread above
contains a simple test case for replicating the problem:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50487

Whether or not it fails depends on the complexity of the walkable area
mask. If the walkable area mask is too complicated for the old
pathfinder, pathfinding fails.

The culprit is some code in __find_route that prevents AGS from using
the Dijkstra pathfinder when navigating along a vertical or horizontal
path. The consequences of using Dijkstra in these cases aren't clear,
but the current check for vertical and horizontal lines appears to make
a faulty assumption:

```
;            // don't use new algo on arrow key presses
```

I think this is bogus because:

Keyboard movement modules bundled with AGS use WalkStraight.
WalkStraight calls can_see_from, but does not use the main find_route
function. (It's possible that this is an old comment. In the past, there
might have been some code that called find_route from WalkStraight.)

This commit makes the Dijkstra pathfinder the preferred pathfinder,
defaulting only to the old pathfinder when Dijkstra (rarely) fails.
Keyboard
movement is handled with can_see_from (basically a best-first search)
and
has no real relevance to the pathfinder.

This is a revision of a previous commit that erroneously removed the
pathfinding code altogether. It would seem that our Dijkstra algorithm
isn't a
fully correct implementation (which should cover the test area in < 5000
iterations) and might need to be revisited in future. My recommendation
would
be to implement A* in a future release. For now, this fixes the original
bug
and gives people the pathfinding they expect (retaining backwards
compatibility).
Revert "Debian: Ignore that agslua is not in the source traball, because it's a git submodule."

This reverts commit 721ab9528864215c18ff3f86675fd934fccb1bc0.

agslua should be built into ags+libraries, not removed from the orig source tarball.
Build ags+libraries with agslua plugin.
Merge pull request #212 from gurok/340_fixed_pathfinding

Bugtracker -- Pathfinding on horizontal and vertical lines (take 2)
Script API: implemented Mouse.Click()
Script API: renamed ProcessClick() to Room.ProcessClick()
Engine: added const modifier to several script related functions
Engine: refactored queued script

This moves the queued script description to the separate struct; stores the function type and param count in dedicated variables, as opposed to adding and then parsing a prefix on function name.
Engine: picked out algorithm for queueing script function
Engine: support calling gui OnClick handlers from script
Script API: implemented GUI.Click() and Button.Click()
Engine: split GUI mouse interaction out from check_controls() function
Common: replaced GUIMain::IsMouseOnGUI() with IsInteractableAt()
Script API: implemented GUI.ProcessClick()
Scripting: Implemented System.RuntimeInfo

Implemented a read-only `System.RuntimeInfo` String property that
returns the information displayed when pressing Ctrl+V in a game. The
debug implementation of `debug(1, 0)` still works in debug mode.
Internally, it just calls `System_GetRuntimeInfo` and displays the info.
The `System.RuntimeInfo` property exists in debug or release mode. The
user may implement the display of this info however s/he likes.
Merge pull request #213 from gurok/340_runtimeinfo

Scripting: Implemented System.RuntimeInfo
Script: support "dialog_options_repexec" callback

This adds support for "dialog_options_repexec" script callback that is called by engine each tick when custom dialog options are on screen.
Script: support "dialog_options_key_press" callback

This adds support for "dialog_options_key_press" script callback that is called by engine when a key was pressed while the custom dialog options are on screen.
Script API: implemented DialogOptionsRenderingInfo.Update()