Clean up code documentation for display of core compatibility ranges for available module updates

Copying over the NW review from @tedbow in #3096078-36: Display core compatibility ranges for available module updates so it's easier to act on this and get it RTBC:

1. +++ b/core/modules/update/src/ProjectCoreCompatibility.php
   @@ -9,29 +9,21 @@
   + * The only public method, setReleaseMessage(), constructs a list of versions of
   + * Drupal core that a given release is compatible with. The compatible versions
   + * are displayed in ranges to minimize how much text is generated. This list is
   + * used on the available updates report.
   

   I still think it is more helpful to have a shorter class doc. This describes setReleaseMessage() but is not on that method so any automated tool a developer where to use to see the doc for that method would not have this text.

   I use PHPStorm but I think this would be true for any IDE that lets you view the docs when looking at a method call.
   
   above doesn't have this helpful description.

   This would also be true from api.drupal.org. Example method with longer description: https://api.drupal.org/api/drupal/core%21modules%21update%21src%21Update...

2. +++ b/core/modules/update/update.compare.inc
   @@ -110,6 +111,12 @@ function update_calculate_project_data($available) {
   +      // Inject the list of compatible core versions to show site builders which
   ...
   +      // example, 8.9.x and 9.0.x), this list will hopefully help site builders
   

   Just check and we use the the term "administrator(s)" much for often in core comments than we do "site builder". I think it would be good to change to that.

Here I have uploaded a patch, please review it.
I have tried to make changes as suggested in #6.

+++ b/core/modules/update/src/ProjectCoreCompatibility.php
@@ -14,21 +14,28 @@ class ProjectCoreCompatibility {
    * @var string[]

This sentence can just end with "compatibility constraint".

"we don't want to re-compute the same information over and over." is just the reason we cache anything. No need to state that here.

1. +++ b/core/modules/update/src/ProjectCoreCompatibility.php
   @@ -14,21 +14,28 @@ class ProjectCoreCompatibility {
   +   * This list is cached since many project releases will use the same core
   +   * compatibility constraint and we don't want to re-compute the same
   +   * information over and over.
   

   This sentence can just end with "compatibility constraint".

   "we don't want to re-compute the same information over and over." is just the reason we cache anything. No need to state that here.

2. +++ b/core/modules/update/update.compare.inc
   @@ -110,6 +111,12 @@ function update_calculate_project_data($available) {
   +      // Inject the list of compatible core versions to show administrator(s) which
   ...
   +      // example, 8.9.x and 9.0.x), this list will hopefully help administrator(s)
   

   This comments go over the line char limit of 80.

3. +++ b/core/modules/update/src/ProjectCoreCompatibility.php
   @@ -8,27 +8,43 @@
   +   * This list is cached since many project releases will use the same core
   +   * compatibility constraint and we don't want to re-compute the same
   +   * information over and over.
   

   This sentence can just end with "compatibility constraint".

   "we don't want to re-compute the same information over and over." is just the reason we cache anything. No need to state that here.

just a nit on the interdiff

diff --git a/Users/ravi/Downloads/3101547-3096078-35.follow-up-doc-fixes.patch b/Users/ravi/Desktop/contrib-patch/3101547-7.patch
index 7edbb6de66..af84957362 100644
--- a/Users/ravi/Downloads/3101547-3096078-35.follow-up-doc-fixes.patch
+++ b/Users/ravi/Desktop/contrib-patch/3101547-7.patch

having the local files names in the interdiff means others simply apply the interdiff to confirm the changes since the last patch locally.(can't wait for gitlab merge requests😿)

Thanks, @tedbow.

Here I have made changes as suggested in comment #8.

@ravi.shankar thanks for again for the patch.

+++ b/core/modules/update/src/ProjectCoreCompatibility.php
@@ -26,9 +26,7 @@ class ProjectCoreCompatibility {
-   * This list is cached since many project releases will use the same core
-   * compatibility constraint and we don't want to re-compute the same
-   * information over and over.
+   * Compatibility constraint.

We still need the first part of this sentence. So it would be

This list is cached since many project releases will use the same core compatibility constraint.

Other than that patch looks good.

Not sure what happened my review #8 🤦‍♂️ where I added the comment 3 times 🤷‍♂️

Thanks, @tedbow

Here I have again made changes. Please review it.

Sorry, I have mistakenly added .patch extension in "interdiff" of patch #11

Here I have added interdiff of patch #9 and #11

@ravi.shankar thanks! Looks good

these needs to be backported to 8.8.x or #3102724: Improve usability of core compatibility ranges on available updates report will be very hard to backport

Making critical because that issue is critical

#3096078: Display core compatibility ranges for available module updates was committed to 8.8.x!
So now clean re-roll

check locally and this is the exact same file as 3101547-8.8.x-do-not-test.patch