Update references to main branch (apache#10705)

Some docs were referring to `master`, update them to refer to `main`.

site/docs/benchmarks.md

@@ -27,7 +27,7 @@ Also note that JMH benchmarks run within the same JVM as the system-under-test,
 
 It is possible to run one or more Benchmarks via the **JMH Benchmarks** GH action on your own fork of the Iceberg repo. This GH action takes the following inputs:
 * The repository name where those benchmarks should be run against, such as `apache/iceberg` or `<user>/iceberg`
-* The branch name to run benchmarks against, such as `master` or `my-cool-feature-branch`
+* The branch name to run benchmarks against, such as `main` or `my-cool-feature-branch`
 * A list of comma-separated double-quoted Benchmark names, such as `"IcebergSourceFlatParquetDataReadBenchmark", "IcebergSourceFlatParquetDataFilterBenchmark", "IcebergSourceNestedListParquetDataWriteBenchmark"`
 
 Benchmark results will be uploaded once **all** benchmarks are done.

site/docs/concepts/catalog.md

@@ -43,7 +43,7 @@ There are more catalog types in addition to the ones listed here as well as cust
 
 ## Decoupling Using the REST Catalog
 
-The REST catalog was introduced in the Iceberg 0.14.0 release and provides greater control over how Iceberg catalogs are implemented. Instead of using technology-specific logic contained in the catalog clients, the implementation details of a REST catalog lives on the catalog server. If you’re familiar with Hive, this is somewhat similar to the Hive thrift service that allows access to a hive server over a single port. The server-side logic can be written in any language and use any custom technology, as long as the API follows the [Iceberg REST Open API specification](https://github.com/apache/iceberg/blob/master/open-api/rest-catalog-open-api.yaml).
+The REST catalog was introduced in the Iceberg 0.14.0 release and provides greater control over how Iceberg catalogs are implemented. Instead of using technology-specific logic contained in the catalog clients, the implementation details of a REST catalog lives on the catalog server. If you’re familiar with Hive, this is somewhat similar to the Hive thrift service that allows access to a hive server over a single port. The server-side logic can be written in any language and use any custom technology, as long as the API follows the [Iceberg REST Open API specification](https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml).
 
 A great benefit of the REST catalog is that it allows you to use a single client to talk to any catalog backend. This increased flexibility makes
 it easier to make custom catalogs compatible with engines like Athena or Starburst without requiring the inclusion of a Jar into the classpath.

site/docs/how-to-release.md

@@ -84,7 +84,7 @@ This step can be useful to gather ongoing patches that the community thinks shou
 
 The communication can be started via a [DISCUSS] mail on the dev@ channel and the desired tickets can be added to the github milestone of the next release.
 
-Note, creating a milestone in github requires a committer. However, a non-committer can assign tasks to a milestone if added to the list of collaborators in [.asf.yaml](https://github.com/apache/iceberg/blob/master/.asf.yaml)
+Note, creating a milestone in github requires a committer. However, a non-committer can assign tasks to a milestone if added to the list of collaborators in [.asf.yaml](https://github.com/apache/iceberg/blob/main/.asf.yaml)
 
 The release status is discussed during each community sync meeting. Release manager should join the meeting to report status and discuss any release blocker.
 
@@ -101,7 +101,7 @@ Example console output:
 ```text
 Preparing source for apache-iceberg-0.13.0-rc1
 Adding version.txt and tagging release...
-[master ca8bb7d0] Add version.txt for release 0.13.0
+[main ca8bb7d0] Add version.txt for release 0.13.0
  1 file changed, 1 insertion(+)
  create mode 100644 version.txt
 Pushing apache-iceberg-0.13.0-rc1 to origin...