Add loser picks balance algo

This patch allows the `!help` command to show documentation for
the following commands:
- `!setAllAiBonus`
- `!unboss`
- `!setratinglevels`

The help entries for the first two of these was missing because the
permissions configuration was placed in the global `commands.conf`
file, instead of the plugin-specific `BarManagerCmd.conf` file.

The help entry for the last command was missing because of a
copy-paste error (`!resetratinglevels` had two help entries, while
`!setratinglevels` had none).

Fix missing `!help` entries for several BarManager commands.

Currently, `getNumUsersInMyBattle()` throws an error if it is
called when the battle is closed. One way this can happen is in the
`sendTachyonBattle()` timer callback, if the lobby was disconnected
between when the timer was started and when the callback runs.

Currently, `sendTachyonBattle()` is called as a timer callback, to
provide a form of rate-limiting. The timer is only started when a
battle is open, but it is possible that the lobby will disconnect
before `sendTachyonBattle()` runs.

This patch makes `sendTachyonBattle()` return early if the lobby
is no longer connected at the time that it runs.

Currently, the following lobby command handlers log an error if
they are called for a user that is not currently known:
- hLEFT_pre
- hLEFTBATTLE_pre
- hREMOVEUSER_pre
- hCLIENTSTATUS_pre
- hJOINEDBATTLE_pre

When it is logged, the current error message states "hXXX_pre
cannot be exectuted <...>". This message does not clearly explain
what went wrong or what else may be impacted as a result of the
error.

This patch changes the error message to state "hXXX_pre was called
for an unknown user, skipping <...>". This makes it much more
clear what went wrong (missing a user), and what may be impacted
(anything involving that specific user).

Counterintuitively, SPADS calls the `onLobbyConnected` callback
*after* the `onLobbyLogin` callback.

By registering all lobby command handlers in `onLobbyLogin`, we
ensure that we don't miss any commands that would have been sent
before `onLobbyConnected` is run.

Miscellaneous cleanups/fixes

Currently, there is not a reliable way to determine whether a host
is running the latest BarManager code. This is particularly
annoying when making changes to the Integration server, as for
subtle changes it is not easy to tell whether the latest code has
been fetched yet.

This patch adds a new `selfFileHash` variable (set on plugin
init), which calculates a 6-character hash of the currently-running
python file. That variable is also added to the output of
`!barmanagerprintstate`, so that it is easy to look up.

Add `selfFileHash`, and print it in `!barmanagerprintstate`

Follow-up for #170.

Once the `!unboss` command is deployed, and Chobby has been updated
to use it, this patch can be used to disable `!boss` (without
parameters) so that users are not surprised by its behavior.

The Perl code which is currently used to implement the `!unboss` command handler is only valid when the name of the target is alphanumeric.

This patch updates that Perl code, so that it also works when the target's name contains whitelisted symbols.

From commit beyond-all-reason/maps-metadata@5e6ec88

From commit beyond-all-reason/maps-metadata@98dc475

From commit beyond-all-reason/maps-metadata@05a0a8b

…into integration

Currently, if an arbitrary player runs the command `!joinas USER`,
a vote is called among all players in the lobby. As a result,
even if the target player does not want someone to be able to
control their units, the rest of the lobby can overrule them.

This patch makes the following changes, active during any ongoing
`!joinas USERNAME` vote:
- When a non-target submits a vote, the vote state is checked for
 whether USERNAME has voted already. If so, the non-target's vote
 is counted as normal; if not, the non-target's vote is deferred.
- If USERNAME submits a "no" vote, then the ongoing vote is
 immediately ended (as if by `!endVote`) and all deferred votes are
 discarded.
- When USERNAME submits a "yes" or "blank" vote, all deferred votes
 are counted.

This has the practical effect of requiring approval from the
`!joinas` target, in order for the vote to succeed; the vote will
fail if the target does not explicitly vote "yes" or "blank".

Make `!joinas` require approval from its target player.

…ires-target-approval

Revert "Make `!joinas` require approval from its target player."