Evaluate changing user-defined functions that relate to schema changes' APIs

We currently add an extra argument to `worker_apply_shard_command()`, `worker_fetch_regular_table()`, and `worker_fetch_foreign_table()` to incorporate schema names.

We added this argument because we wanted to be more explicit that we have two functions and that we could later remove one of these functions. We also wanted to note that schema name wasn't the first parameter.

An open question is whether we could use `regclass` as an argument type, or took a fully qualified table name as an argument (and used `ResolveRelationId`) -- I'm cool with both choices as long as our apis are consistent. @metdos, I think you noted that if we modeled our APIs this way, we wouldn't be able to do rolling upgrades where the master node is upgraded first. Is this understanding correct?