Summary:
Table locks only expose a local TSLocalLockManager at the TServers, Not the master.
This was because we expect a postgres backend to be only present at the tservers and not the master.

However there are some codepaths where a pg-backend is created at the master, which calls into the mater to do the PerformRpc. This happens during the initdb process. 75ff75e2ecdd02e3fa397dcd64eb7e9baf2528d8 detects such scenarios and disables table locks usage. However, this works only for initdb.

pg_upgrade may also go through a similar codepath taking table locks. This causes the YsqlMajorUpgrade tests to fail. We detect this codepath based on whether or not `IsBinaryUpgrade` is set, and disable table locks for the code path accordingly.

32c777208628 implements a mechanism to block out DDLs during the upgrade process, so we should be ok with disabling table locks here. However, if at a later time, we want to use table locks as the mechanism to enforce this, we should revisit the decision and consider exposing a local-table-locks-manager at the master.
Jira: DB-18106

Test Plan:
run tests with table locks enabled

```
yb_build.sh fastdebug  --cxx-test ysql_major_upgrade-test    --test_args --ysql_yb_ddl_transaction_block_enabled=true --test_args --enable_object_locking_for_table_locks=true --test_args --allowed_preview_flags_csv=enable_object_locking_for_table_locks,ysql_yb_ddl_transaction_block_enabled

yb_build.sh release  --cxx-test ysql_major_upgrade-test    --test_args --ysql_yb_ddl_transaction_block_enabled=true --test_args --enable_object_locking_for_table_locks=true --test_args --allowed_preview_flags_csv=enable_object_locking_for_table_locks,ysql_yb_ddl_transaction_block_enabled
```

Reviewers: rthallam, hsunder, fizaa, bkolagani, #db-approvers

Reviewed By: hsunder

Subscribers: svc_phabricator, yql

Differential Revision: https://phorge.dev.yugabyte.com/D46496