Update library author guide to use the latest actions/setup-java

Also fix a few typos

Author: julienrf

_overviews/contributors/index.md

@@ -22,7 +22,7 @@ that the license and copyright notices are preserved. For the record, Scala itse
 
 Once you have chosen a license, *apply* it to your project by creating a `LICENSE` file in the root directory
 of your project with the license contents or a link to it. This file usually indicates who owns the copyright.
-In our example of [LICENSE file](https://github.com/scalacenter/library-example/blob/master/LICENSE), we have
+In our example of [LICENSE file](https://github.com/scalacenter/library-example/blob/main/LICENSE), we have
 written that all the contributors (as per the Git log) own the copyright.
 
 ## Host the Source Code
@@ -31,15 +31,15 @@ We recommend sharing the source code of your library by hosting it on a public [
 hosting site such as [GitHub](https://github.com), [Bitbucket](https://bitbucket.org) or [GitLab](https://gitlab.com).
 In our example, we use GitHub.
 
-Your project should include a [README](https://github.com/scalacenter/library-example/blob/master/README.md) file
+Your project should include a [README](https://github.com/scalacenter/library-example/blob/main/README.md) file
 including a description of what the library does and some documentation (or links to the documentation).
 
 You should take care of putting only source files under version control. For instance, artifacts generated by the
 build system should *not* be versioned. You can instruct Git to ignore such files by adding them to a
-[.gitignore](https://github.com/scalacenter/library-example/blob/master/.gitignore) file.
+[.gitignore](https://github.com/scalacenter/library-example/blob/main/.gitignore) file.
 
 In case you are using sbt, make sure your repository has a
-[project/build.properties](https://github.com/scalacenter/library-example/blob/master/project/build.properties)
+[project/build.properties](https://github.com/scalacenter/library-example/blob/main/project/build.properties)
 file indicating the sbt version to use, so that people (or tools) working on your repository will automatically
 use the correct sbt version.
 
@@ -71,32 +71,35 @@ jobs:
   ci:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2 # Retrieve the content of the repository
-      - uses: actions/setup-java@v2 # Set up a jdk
+      - uses: actions/checkout@v3 # Retrieve the content of the repository
+      - uses: actions/setup-java@v3 # Set up a jdk
         with:
           distribution: temurin
           java-version: 8
+          cache: sbt # Cache the artifacts downloaded by sbt accross CI runs
       - name: unit tests # Custom action consisting of a shell command
         run: sbt +test
 ~~~
 
 This workflow is called *Continuous integration* and it will run every time one
 or more commits are pushed to the repository. It contains only one job called
 *ci*, which will run on an Ubuntu runner and that is composed of three
-actions.  The action `setup-scala` installs the sbt launcher in the runner. Then
-the job runs `sbt +test`, which loads the sbt version specified in
+actions. The action `setup-java` installs a JDK and caches the library dependencies
+downloaded by sbt so that they are not downloaded again everytime the CI runs.
+
+Then, the job runs `sbt +test`, which loads the sbt version specified in
 `project/build.properties`, and runs the project tests using the Scala version
 defined in the file `build.sbt`.
 
 The workflow above will run at any push to any branch of the repository. You
 can specify the branch or add more triggers such as pull requests, releases,
 tags or schedules. More information about workflow triggers is available
 [here](https://docs.github.com/en/actions/reference/events-that-trigger-workflows).
-while the `setup-scala` action is hosted [in this
-repository](https://github.com/olafurpg/setup-scala).
+while the `setup-java` action is hosted [in this
+repository](https://github.com/actions/setup-java).
 
 For reference, here is our complete [workflow example
-file](https://github.com/scalacenter/library-example/blob/master/.github/.workflows/ci.yml).
+file](https://github.com/scalacenter/library-example/blob/main/.github/workflows/ci.yml).
 
 ## Publish a Release
 
@@ -309,10 +312,14 @@ jobs:
   release:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
+        with:
+          fetch-depth: 0 # fetch all tags, required to compute the release version
+      - uses: actions/setup-java@v3
         with:
-	  fetch-depth: 0 # fetch all tags, required for sbt-dynver
-      - uses: olafurpg/setup-scala@v12
+          distribution: temurin
+          java-version: 8
+          cache: sbt
       - run: sbt ci-release
         env:
           PGP_PASSPHRASE: ${{ secrets.PGP_PASSPHRASE }}
@@ -561,8 +568,14 @@ jobs:
   publishSite:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
-      - uses: olafurpg/setup-scala@v12
+      - uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-java@v3
+        with:
+          distribution: temurin
+          java-version: 8
+          cache: sbt
       - name: Generate site
         run: sbt makeSite
       - uses: JamesIves/github-pages-deploy-action@4.1.3
@@ -585,7 +598,7 @@ Add a `CONTRIBUTING.md` file to your repository, answering the following questio
 What are the coding practices to follow? Where are the tests and how to run them?
 
 For reference, you can read our minimal example of
-[`CONTRIBUTING.md` file](https://github.com/scalacenter/library-example/blob/master/CONTRIBUTING.md).
+[`CONTRIBUTING.md` file](https://github.com/scalacenter/library-example/blob/main/CONTRIBUTING.md).
 
 ### Issue Labels