[crossfire] requestable party lists

[Brendan Lally]

I have uploaded a patch to the sourceforge tracker which forms an
initial proposal for requestable party lists.
 https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id=13833&atid=313833

It is designed to allow clients to provide their own interfaces to
party interaction, removing the need to use the (rather complex) party
 commands.

[The following are the proposed modifications to doc/Developers/protocol]

That there be a new setup option:

  partysend (0/1)
       If 1, the client should be sent the name of their current party
       in the stats packet.

That there be a new requestinfo type

  party_list (no parameters)
      This returns the list of parties currently active on the server.
This can be used by clients to present a list of parties to choose
from.

      All data is sent in text format. Format is:

      name:leader:number of players:whether there is a password set

      eg

      foo:bar:2:0

      is a party called foo, let by bar with 2 players and no password

      bar:baz:12:1

      is a party called bar led by baz with 12 players and a password
that is needed to join.

[end of proposal.]

[The rest of this is an edited and modified form of the description on
the patch tracker.]

 Specifically, it adds a new requestinfo type,  party_list which
returns a list of all parties  currently active on the server, and a
new stat byte, 32, which gives the name of the party the player is
currently in (there is also a new setup flag to  define whether that
should be sent - possibly this should be extended to include other
things that should be added to the stats command about now).

Parties are now joined using party join partyname:password rather than
prompting for the password seperatly. However currently I have this
new style of party password transmission running in parallel with the
old one. Nevertheless, I am inclined to say that the old style could
be removed now, since the way I implement this, even non-supporting
clients can still authenticate to a party (albeit without the masking
of input in the text window)

 One other upshot of this approach is that ':' needs to be a forbidden
character in party names, and they can not be longer than 255
characters (although this is longer than cfclient's current entry
buffer).

[end of description]

Please comment, suggest, flame, etc away. If it is felt that I should
send this information in a different way/format, I would prefer to
know now, rather than after writing client support.