kernel: Do not use gSchedulerLock when accesing UID and GID

Reads and writes to uid_t and gid_t are atomic anyway. The only real
problem that may happen here is inconsistent state of triples
effective_{u, g}id, saved_set_{u, g}id, real_{u, g}id, but team locks
protect us against that.
kernel/lock: Do not use *_locked() functions when not needed
kernel: Add thread_unblock() and use it where possible