[crossfire] server commit for map2 support.

[Mark Wedel]

  I just committed the code that adds the map2 protocol command to the server. 
I played around with it quite a bit and didn't notice anything odd.

  A few worthy notes however:

1) Support for the original map command was removed.  Clients as of 1.2 (or 
thereabouts) have support for the map1 command, so it shouldn't effect much. 
Rather than drop the connection to a client that doesn't request decent map 
support, a message is instead printed out.  I decided to do this in case any 
scripts were out there that didn't care about map data and thus never did a 
'setup map1' - I thought that could lead to a connect, do setup, get bumped, 
connect, etc cycle.

  Interestingly enough, other than not being able to see anything, the server 
should still let you (or the bot) play in this case, just lacking any map 
information.  So for bots that just watch messages or other events, this could 
actually save them a little bandwidth.

2) the map2 has support for 10 layers.  However, compared to the old 3 layer 
method where it tried to find something to fill each of those 3 layers, 
different layers are well defined to hold specific data (objects, monsters, 
etc).  So you will probably never see all 10 layers filled with something at the 
same time.  But you can pretty easily see 5 or 6 layers filled (stand on floor 
with a sign, drop 3 objects, and have someone cast a spell over you :)

  One of the main reasons for doing this is that one of the problems with the 
old client is objects shifting layers - this caused more a problem with big 
images and whether they should or should not be erased.

  The old portion of 3 layers in the map structure is removed.  Instead, in the 
map1 draw code, it looks at the 10 objects and figures out which are visible and 
thus which to draw.  This is probably a little bit more cpu intensive than the 
old method.

3) the map2 protocol adds support for clients to handle map animations.  On my 
test server, I did the ocean spaces and the fountains and it works just fine - 
I'll probably modify more archetypes.

  My thought for the first group of objects are those that are always the same 
speed and never change (ocean, fountains, grass, etc).

  With the client being able to handle the client animation, there is now no 
need for these objects to have any object speed.  Removing speed from these 
objects is likely to free up a fair amount of server load.

  The one problem with doing so is that clients not using the map2 protocol 
won't see these objects being animated anymore.  My personal thought is that 
this isn't that big a deal - the animation of these objects is more window 
dressing than anything important, and also if people do care, perhaps that would 
speed them up to updating their client.

  Thoughts/comments?