While what chanroles are trying to accomplish is a good idea, it is
apparently unclear this is the proper way to do it. Until we figure out
the exact way we wish to do this, it should be reverted for now.
The theory behind this is that services sends an ENCAP * GRANT #channel
UID :+flagspec message specifying the chanroles the user has. They are
mapped into flag bits and applied to the membership of the user. They
then are restricted or permitted to what they can do based on the
permissions mask regardless of rank.
For backwards compatibility, the default permission bit (without a GRANT
statement) allows a user to to anything an existing op can do ONLY if
they are an op.
Todo: make CHANROLE_STATUS work (the ability to apply +ov to people),
which is at the moment controlled by CHANROLE_MODE.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
(resv, cmode +m, cmode +b, cmode +q, etc.).
This is only checked for local users.
For optimal compatibility, a failure for this reason still
returns ERR_CHANOPRIVSNEEDED.
Side effect: normal users cannot change topics of resv'ed
channels, even if they have ops, just like they already
cannot send messages. This only matters if resv_forcepart
is disabled, as the user would have been removed from the
channel otherwise.
