Make it clear which scope is covered by with_lock(mu): instead of
implicitly having it from with_lock till end of current block

		with_lock(mu);
		...
	} // end of current block

make it to be the statement covered by with_lock, as if with_lock was
e.g. an `if`, for example:

	with_lock(mu)
		do_something();
	// mu released here

or

	with_lock(mu) {
		do_smth1();
		do_smth2();
	} // mu released here

This makes the intent in __chanselect2 more clear: it was

	ch->_mu.lock();
	with_lock(g->_mu);
		...
	ch->_mu.unlock();

and semantically human expects g->mu to be released _before_
ch->_mu.unlock(). However with current with_lock implementation, g->mu
will be released _after_ ch->_mu.unlock(), which goes against intuition.

-> By reworking with_lock implementation to cover only next statement or
block of code we make sure that g->_mu will be released _before_
ch->_mu - the same way as it was until 3b241983 (Port/move channels to
C/C++/Pyx):

	ch->_mu.lock();
	with_lock(g->_mu) {
		...
	}
	ch->_mu.unlock();