BugFix: Fix original coding errors creating data in TArea::exits member

The specification for this member is:
```
QMultiMap\<int, QPair\<int, int> > exits
```
and it is a record of the rooms that are on border on the TArea instance.
The outer QMultiMap key is the room id of the in_area room, and the value
pair is:
```
first=out_of_area room id
second=direction code
```
The original direction codes were defined at the start of the TArea.cpp
class file but there did not appear to be any logic to the values used:
N=12, NE=1, E=3, SE=4, S=6, SW=7, W=9, NW=10, UP=13, DOWN=14, IN=15,
OUT=16, OTHER=17.  Other than a lua function getAreaExits(areaId) which was
supposed to return just a list of unique keys via a TArea::getAreaExits()
method - i.e. a list of rooms in the given area which were exits to another
area, no other use was made of this data.  I propose to replace this list
of values with the better known list stored in the TRoom class header file
but as that does not currently have a value for "other" {a.k.a. Special}
exits I had added a new define: #DEFINE DIR_OTHER with the value 13.

The data IS stored in the map file but is not changed except by calls to:
```
* (void)TArea::ausgaengeBestimmen() called from:
    (void)TRoomDB::initAreasForOldMaps()
* (void)TArea::fast_ausgaengeBestimmen(int id) called from:
    (bool)TMap::setExit(int from, int to, int dir)
    (void)TRoom::setArea(int _areaID)
    (void)TRoom::setSpecialExit(int to, const QString & cmd)
    (void)TRoom::removeAllSpecialExitsToRoom(int _id)
    (void)dlgRoomExits::save()
* (void)TArea::removeRoom(int room) called from:
    (void)TRoom::setArea(int _areaID)
    (bool)TRoomDB::__removeRoom(int id)
```
The bugs are that the code in both "ausgaengeBestimmen" methods (with
and without the "fast_" prefix) used the FROM room Id as the first member
of the value pair rather than the TO (a.k.a. exit) room Id for Normal
exits and use the room ID of the TO (a.k.a. exit) room Id as the key for
Special exits (i.e. stores a room that is NOT in the relevant area as a
room IN the area that is an exit from THAT area!)  Additionally, even if
the code was correct the existing flawed data would not be corrected when
the map is loaded by running TArea::ausgaengeBestimmen() again because that
is only called at the end of TRoomDB::initAreasForOldMaps() which was
called only for old pre-version 15 map file formats (and we are currently
on 16 - though I have plans in pipeline for something that would require an
increment on that).  To further stir the faulty data up previous faulty
code that introduced problems when moving a room from one area to another
may also have contributed to errors with the TArea::exits data.

However:

tl;dr;

running the lua command "auditAreas()" runs TRoomDB::initAreasForOldMaps()
which will fix-up existing maps after this commit has been committed...!

This fixes ["getAreaExits is broken (bug 1380822)"](http://bugs.launchpad.net/mudlet/+bug/1380822) 8-)

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Right, let me reiterate how I see this so I have it clear:
* If the user's script supplies incorrect _types_ of arguments that cannot be _coerced_(?) into the wanted one, throw a lua_error() which aborts things and passes a message back to the user about the first argument that is not right - that message should begin with the name of the function that encountered the problem, without "()" but followed by a ':'. This message IMHO _ought_ to be translated via a Qt tr(\<message>).toUtf8().constData() wrapper when we go multi-lingual as it will help to inform the user in their own language what the problem is. Not furnishing enough mandatory arguments should now be caught by the _current_ _standard_ type checking tests {with lua_pushstring( L, tr("\<funtionname>: bad argument \#_N_ (..., got %1).arg( luaL_typename, _N_).toUtf8().constData() ) } type messages as the automatically generated _nil_ values that the missed out arguments get will trip the type checks.
* If the user's script supplies the correct type of arguments, but one or more values is outside of the acceptable _range_ of values the first return value is a _nil_ and a second value, a message about the problem value should be returned.  Like the message in the previous case, in my option, that message should, in the future, be subject to translation into the user's language of choice as it is intended to inform them of the problem rather than be parsed for meaning by other scripts.
* If the user's script supplies the correct type of arguments, and all values are inside of the acceptable _range_ of values but there is no data to return for that particular set of values then an empty table "{}" or string ""  should be returned.  _We should avoid returning_ nil _in this situation_... 
* For the _normal_ case the expected data should be returned, without further strings attached :stuck_out_tongue_winking_eye: - I'm not entirely convinced of this, unless it is essential that the additional message provision for wrong _value_ arguments __must__ be _nil_ when things are :ok:, as a script writer I'd welcome positive outcome messages when debugging stuff unless they get in the way by decreasing the Signal-to-Noise ratio of debugging message.

In the case where a function does produce a multi-value return in the event of a bad argument _value_ should all of those values get set to _nil_ then the extra error message gets tagged on?  I was going to quote my getMudletVersion() when supplied with a single (literal) string of "table" as an argument - which produces a multi-value return but that would be a bad example because it only does a multi-value return if the (incorrectly chosen) string "table" is supplied so this situation does not apply.

Discuss :question: 
If I can get a good grip on this I would consider writing it up for the wiki / sticky it in the development forum :grin: