Fix SRO + multi-table update statements in replication

Bug fix for when a multi-table update statement is binlogged in statement form and the slave is in super read only.

This also pulls the code to check for RO into an inline function and replaces other occurrences to reduce the likelihood of this happening again.
Hello Santosh,

The error is related to running a slave in super-read-only with statement or mixed replication, then executing a multi-table update statement on the master.  Specifically, if you have SRO set on the slave, then execute the following on the master, replication will break on the update statement:
```sql
create table t1(a int);
create table t2(a int, b int);
insert into t1 values(1), (2);
insert into t2 (a) values (1), (2), (3), (4);
update t2 natural join t1 set b=3;
```

The message when it breaks is:
> Error 'The MySQL server is running with the --read-only (super) option so it cannot execute this statement' on query. Default database: 'test'. Query: 'update t2 natural join t1 set b=3'

The problem is in sql_parse.cc lines 3834-3836, in that it isn't considering the value of thd->slave_thread (which is considered on lock.cc:201, handler.cc:1479, and sql_trigger.cc:464).  I included the change to transaction.cc because it used similar logic and was also missing the check for slave_thread, though I'm not sure if/what error that one would generate.

The reason for the refactoring was to prevent any future issues with this, since everything could just start checking the function instead.