Clarify RC wording in release docs

An RC is technically only one of a few "pre-release" labels (alpha, beta, rc)

docs/en/05_Contributing/04_Making_A_SilverStripe_Core_Release.md

@@ -91,7 +91,7 @@ When doing a security release, typically one or more (or sometimes all) of the b
 steps will need to be performed manually. As such, this guide should not be followed
 exactly the same for these.
 
-Standard practice is to produce an RC for any patched modules on the security 
+Standard practice is to produce a pre-release for any patched modules on the security 
 forks for cms and framework (see [silverstripe-security](https://github.com/silverstripe-security)).
 
 <div class="warning" markdown="1">
@@ -117,8 +117,8 @@ Producing a security fix follows this general process:
 * Push the current upstream target branches (e.g. 3.2) to the corresponding security fork
   to a new branch named for the target release (e.g. 3.2.4). Security fixes should be 
   applied to this branch only. Once a fix (or fixes) have been applied to this branch, then
-  an RC tag can be applied, and a private release can then be developed in order
-  to test this RC.
+  a tag can be applied, and a private release can then be developed in order
+  to test this release.
 * Once RC testing is completed and the release is ready for stabilisation, then these fixes
   can then be pushed to the upstream module fork, and the release completed as per normal.
   Make sure to publish any draft security pages at the same time as the release is published (same day).
@@ -131,16 +131,16 @@ can be published as soon as a workaround or usable resolution exists.
 
 ## Standard release process
 
-The release process, at a high level, involves creating an RC, publishing it, and 
-reviewing the need for either another RC or a final stable tag within a short period
+The release process, at a high level, involves creating a release, publishing it, and 
+reviewing the need for either another pre-release or a final stable tag within a short period
 (normally within 3-5 business days).
 
-During the RC cycle a temporary RC branch is created, and should only receive
-absolutely critical fixes during the RC cycle. Any changes to this branch should
-result in the requirement for a new RC, thus a higher level of scrutiny is typically
+During the pre-release cycle a temporary branch is created, and should only receive
+absolutely critical fixes during the cycle. Any changes to this branch should
+result in the requirement for a new release, thus a higher level of scrutiny is typically
 placed on any pull request to these branches.
 
-When creating a new RC or stable, the following process is broken down into two
+When creating a new pre-release or stable, the following process is broken down into two
 main sets of commands:
 
 ### Stage 1: Release preparation:
@@ -168,7 +168,7 @@ This command has the following parameters:
   newest 3.2.x version). You can normally leave this out for patch releases,
   and the code will normally be able to guess the right version, but you may
   as well declare it every time.
-* `--branch-auto` Will automatically create a new RC branch (e.g. 3.2.4) if
+* `--branch-auto` Will automatically create a new temporary release branch (e.g. 3.2.4) if
   one does not exist.
 
 This can take between 5-15 minutes, and will invoke the following steps,
@@ -180,10 +180,10 @@ and needs to be manually advanced):
   will look at the available versions and branch-aliases of silverstripe/installer
   to determine the best version to install from. E.g. installing 4.0.0 will
   know to install dev-master, and installing 3.3.0 will install from 3.x-dev.
-  If installing RC versions for stabilisation, it will use the correct RC
-  branch.
+  If installing pre-release versions for stabilisation, it will use the correct
+  temporary release branch.
 * `release:branch` If release:create installed from a non-rc branch, it will
-  create the new RC branch (via `--branch-auto`). You can also customise this branch
+  create the new temporary release branch (via `--branch-auto`). You can also customise this branch
   with `--branch=<branchname>`, but it's best to use the standard.
 * `release:translate` All upstream transifex strings will be pulled into the
   local master strings, and then the [api:i18nTextCollector] task will be invoked
@@ -235,7 +235,7 @@ As with the `cow release` command, this step is broken down into the following
 subtasks which are invoked in sequence:
 
 * `release:tag` Each module will have the appropriate tag applied (except the theme).
-* `release:push` The RC branches and all tags are pushed up to origin on github.
+* `release:push` The temporary release branches and all tags are pushed up to origin on github.
 * `release:archive` This will generate a new tar.gz and zip archive, each for
   cms and framework-only installations. These will be copied to the root folder
   of the release directory, although the actual build will be created in temporary
@@ -252,11 +252,11 @@ Once all of these commands have completed there are a couple of final tasks left
 aren't strictly able to be automated:
 
 * If this is a stable release, it will be necessary to perform a post-release merge
-  on open source. This normally will require you to merge the RC branch into the
+  on open source. This normally will require you to merge the temporary release branch into the
   source branch (e.g. merge 3.2.4 into 3.2), or sometimes create new branches if
   releasing a new minor version, and bumping up the branch-alias in composer.json.
   E.g. branching 3.3 from 3, and aliasing 3 as 3.4.x-dev. You can then delete
-  the temporary RC branches. This will need to be done before updating the 
+  the temporary release branches. This will need to be done before updating the 
   release documentation in stage 3.
 * Merging up the changes in this release to newer branches, following the 
   SemVer pattern (e.g. 3.2.4 > 3.2 > 3.3 > 3 > master). The more often this is
@@ -298,7 +298,7 @@ will need to be regularly updated.
 
 * Make sure that the [download page](http://www.silverstripe.org/download) on
   silverstripe.org has the release available. If it's a stable, it will appear
-  at the top of the page. If an RC pre-release, it will be available under the 
+  at the top of the page. If it's a pre-release, it will be available under the 
   [development builds](http://www.silverstripe.org/download#download-releases)
   section. If it's not available, you might need to check that the release was
   properly uploaded to aws s3, or that you aren't viewing a cached version of