Linking mentions of atomic module to doc (#2153)

* Linking mentions of atomic module to doc

* Update data/news/multicore/multicore-2020-03.md

Co-authored-by: Christine Rose <christinerose@users.noreply.github.com>

---------

Co-authored-by: Christine Rose <christinerose@users.noreply.github.com>

data/news/multicore/multicore-2020-03.md

@@ -29,7 +29,7 @@ Onto the details! The various ongoing and completed tasks for Multicore OCaml ar
 * [ocaml-multicore/ocaml-multicore#240](https://github.com/ocaml-multicore/ocaml-multicore/pull/240)
   Proposed implementation of threads in terms of Domain and Atomic
 
-  A new implementation of the `Threads` library for use with the new `Domain` and `Atomic` modules in Multicore OCaml has been proposed. This builds Dune 2.4.0 which in turn makes it useful to build other packages. This PR is open for review.
+  A new implementation of the `Threads` library (for use with the new `Domain` and [`Atomic`](/api/Atomic.html) modules in Multicore OCaml) has been proposed. This builds Dune 2.4.0, which in turn makes it useful to build other packages. This PR is open for review.
 
 * [ocaml-multicore/safepoints-cmm-mach](https://github.com/anmolsahoo25/ocaml-multicore/tree/safepoints-cmm-mach)
   Better safe points for OCaml
@@ -123,4 +123,4 @@ The [Sandmark](https://github.com/ocaml-bench/sandmark) performance benchmarking
 
   The [ocaml/ocaml#9293](https://github.com/ocaml/ocaml/pull/9293) "Use addrmap hash table for marshaling" PR has been re-implemented using a hash table and bit vector, thanks to @xavierleroy. This is a pre-requisite for Multicore OCaml that uses a concurrent garbage collector.
 
-As always, we thank the OCaml developers and users in the community for their code reviews, support, and contribution to the project. From OCaml Labs, stay safe and healthy out there!
+As always, we thank the OCaml developers and users in the community for their code reviews, support, and contribution to the project. From OCaml Labs, stay safe and healthy out there!

data/tutorials/guides/1wf_01_debugging.md

@@ -498,8 +498,8 @@ happening in parallel and prints a back trace for both:
 
 Looking again at our program, we realize that these two writes are in
 fact not coordinated. One possible fix is to replace our mutable
-record field with an `Atomic` that guarantees each such write to
-happen fully, one after the other:
+record field with an [`Atomic`](/api/Atomic.html) that guarantees each
+such write to happen fully, one after the other:
 
 ```ocaml
 (* file race.ml *)

data/tutorials/guides/1wf_04_multicore_ready.md

@@ -339,7 +339,7 @@ simple test runner, one `Domain` may complete before the second has
 even started up yet! This is problematic, as there will be no apparent
 parallelism for TSan to observe and check. In the above example, the
 calls to `Unix.sleepf` help ensure that the test runner is indeed
-parallel. A useful alternative trick is to coordinate on an `Atomic`
+parallel. A useful alternative trick is to coordinate on an [`Atomic`](/api/Atomic.html)
 to make sure both `Domain`s are up and running before the parallel
 test code proceeds. To do so, we can adapt our parallel test runner as
 follows: