Fix alliedmodders#1768

The `sm_admin`-triggered Menu flow for banning players is caching client
indices inside the basebans.sp `PlayerInfo` struct, and can then
incorrectly use them in the menu callback without checking for the
related client's UserId validity. This leads to bug alliedmodders#1768 occurring when
the ban target player disconnects from the server before the banning
admin could complete the banmenu UI flow.

Since the related menu callbacks can't rely on the cached client index,
I have removed the basebans.sp `PlayerInfo.banTarget` member entirely,
in favor of the `PlayerInfo.banTarget`, and instead call
`GetClientOfUserId(...)` to get & validate the target client index where
necessary. The `PrepareBan(...)` function has been refactored to take a
ban target UserId (instead of the target client index) accordingly.

When an admin initiates a ban from a BaseBans GUI menu, track players by
their AuthId (SteamID) instead of userid, so that the admin is able to
target players who disconnect after that menu was constructed.

If the target player is still connected, use their userid to ban the
same as before this commit.

If the target has disconnected, write a ban using their stored AuthId
value, as with "sm_addban".

This commit also revertss the `(admin==0)` check from PrepareBan that
was mistakenly added by bf72128,
because it would prevent banning from server/RCON (client index 0).

Only fall back to authid lookup if userid no longer resolved to client index

In function "PrepareBan", use the global PlayerInfo struct array
members directly, instead of passing them as function parameters.

Unify the client validity checks with AddTargetsToMenuByAuthId checks

Use MAX_TARGET_LENGTH over defining a new custom length