'Connect to replica, migrate to master' operation mode also requires a secondary Amazon RDS Aurora cluster

**Suggesting a documentation update.** Opening up for discussion before PR creation.

In the current documentation, only the 'migrate/test on replica' operation mode is mentioned to need a separate, secondary Amazon RDS Aurora cluster to act as the replica. But the 'Connect to replica, migrate to master' operation mode also requires a secondary cluster.

When testing the 'Connect to replica, migrate to master' mode with [host=reader instance endpoint](https://github.com/github/gh-ost/blob/master/doc/cheatsheet.md#:~:text=123456%22%20%5C%0A%2D%2D-,host%3Dreplica.with.rbr.com,-%5C%0A%2D%2Ddatabase%3D%22):
```
gh-ost \
--user="useradmin" \
--ask-pass \
--host=xxxxxxxx.ca-central-1.rds.amazonaws.com \
--database=dbtest \
--table=persons \
--verbose \
--alter="engine=innodb" \
--assume-rbr \
--allow-master-master \
--cut-over=default \
--exact-rowcount \
--concurrent-rowcount \
--default-retries=120
```

The output is:
```
2023-08-15 13:04:23 INFO starting gh-ost 1.1.5
2023-08-15 13:04:23 INFO Migrating `dbtest`.`persons`
2023-08-15 13:04:24 INFO inspector connection validated on xxxxxxxxx.ca-central-1.rds.amazonaws.com:3306
2023-08-15 13:04:24 INFO User has REPLICATION CLIENT, REPLICATION SLAVE privileges, and has ALL privileges on `dbtest`.*
2023-08-15 13:04:24 INFO Tearing down inspector
2023-08-15 13:04:24 FATAL xxxxxxxxxxx.ca-central-1.rds.amazonaws.com:3306 must have binary logs enabled
```
This is the same error encountered when using 'Migrate/test on replica' mode with a reader instance in the same cluster as its writer instance.

Note: Binary logs have already been enabled on the cluster. From the [AWS docs](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html#:~:text=Binary%20logs%20are%20accessible%20only%20from%20the%20primary%20DB%20instance%2C%20not%20from%20the%20replicas.): “Binary logs are accessible only from the primary DB instance, not from the replicas.”

When a secondary Aurora cluster with a writer instance was created to act as the replica for the primary Aurora cluster, the 'Connect to replica, migrate to master' works as expected.

Happy to create a PR to update the documentation.