_content/doc: fix module and tutorial bugs and clean up flow

For golang/go#44241

- Fix issues 2, 3, 8, 16, 17, 18 from golang/go#44241

Other changes in multiple topics:

- In markdown, replace HTML anchor tags with {#anchor} tags.
- In a few places, add content to clarify that module path must
  be a location from which the module can be downloaded.
- Where it was missing, add example.com domain to example module
  paths. Hopefully, this will reinforce the idea that the module
  path should typically include a domain. Docs will use
  something that looks like a domain name for module path.
- Add more cross-references from tutorial to references for
  packages and commands.
- Rewrite a few links so that they include the topic title,
  rather than simply inline text. Left those links whose
  destinations are references -- the item's name seems to
  suggest that a reference is at the destination.
- Remove domain name from golang.org doc links, leaving root
  directory. Such as /cmd/go/* or /doc/modules/*
- Add path up to root for all links in the same domain.
  Some were linking by file name only.
- Change standard library links from golang.org to pkg.go.dev.

Changes in the module tutorial:

- Add text to help clarify that there should be a hello and
  greetings directory as siblings in their directory hierarchy.
  Some users thought one should be subordinate to the other.
- Where needed, reorder steps so that `go mod init` is run before
  code is added. This is intended to reinforce the importance of
  the module's presence.
- In require/replace steps, have the user use `go mod edit`
  rather than editing the go.mod file in an editor. The tools
  are more likely to yield a functioning result.
- Where possible/appropriate, change module directive link
  destinations from "Modules reference" to go.mod reference.
- Change "run the code" steps so that they all use `go run .`
  rather than `go build` or `go run <filename>`. This removes
  the impedance of explanation and more commands, while
  moving the explanation of `go build` and `go install` to
  a separate topic where they share a clearer context.
- Add a "Conclusion" topic with a few links. The tutorial ended
  rather abruptly before.
- Minor edits to remove some redundant language.

Change-Id: I93055035d73c362ba73edea458fc53bc45e66512
Reviewed-on: https://go-review.googlesource.com/c/website/+/297531
Trust: Steve Traut <straut@google.com>
Run-TryBot: Steve Traut <straut@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

_content/doc/code.html

@@ -78,7 +78,7 @@ <h2 id="Command">Your first program</h2>
 $ cat go.mod
 module example.com/user/hello
 
-go 1.14
+go 1.16
 $
 </pre>
 
@@ -323,16 +323,17 @@ <h3 id="ImportingRemote">Importing packages from remote modules</h3>
 </pre>
 
 <p>
-When you run commands like <code>go install</code>, <code>go build</code>, or
-<code>go run</code>, the <code>go</code> command will automatically download the
-remote module and record its version in your <code>go.mod</code> file:
+Now that you have a dependency on an external module, you need to download that
+module and record its version in your <code>go.mod</code> file. The <code>go
+mod tidy</code> command adds missing module requirements for imported packages
+and removes requirements on modules that aren't used anymore.
 </p>
 
 <pre>
-$ go install example.com/user/hello
+$ go mod tidy
 go: finding module for package github.com/google/go-cmp/cmp
-go: downloading github.com/google/go-cmp v0.4.0
-go: found github.com/google/go-cmp/cmp in github.com/google/go-cmp v0.4.0
+go: found github.com/google/go-cmp/cmp in github.com/google/go-cmp v0.5.4
+$ go install example.com/user/hello
 $ hello
 Hello, Go!
   string(
@@ -342,9 +343,9 @@ <h3 id="ImportingRemote">Importing packages from remote modules</h3>
 $ cat go.mod
 module example.com/user/hello
 
-go 1.14
+go 1.16
 
-<b>require github.com/google/go-cmp v0.4.0</b>
+<b>require github.com/google/go-cmp v0.5.4</b>
 $
 </pre>
 

_content/doc/modules/developing.md

@@ -25,18 +25,17 @@ To support developing, publishing, and using modules, you use:
 	[Versioning](#versioning).
 *   **Go tools** that make it easier for other developers to manage
 	dependencies, including getting your module's source, upgrading, and so on.
-	See [Managing dependencies](managing-dependencies).
+	See [Managing dependencies](/doc/modules/managing-dependencies).
 
 **See also**
 
 *   If you're interested simply in using packages developed by others, this
 	isn't the topic for you. Instead, see [Managing
 	dependencies](managing-dependencies).
 *   For a tutorial that includes a few module development basics, see
-	[Tutorial: Create a Go module](https://golang.org/doc/tutorial/create-module).
+	[Tutorial: Create a Go module](/doc/tutorial/create-module).
 
-<a id="workflow" ></a>
-## Workflow for developing and publishing modules
+## Workflow for developing and publishing modules {#workflow}
 
 When you want to publish your modules for others, you adopt a few conventions to
 make using those modules easier.
@@ -51,8 +50,7 @@ and versioning workflow](release-workflow).
 1. Over time, revise the module with versions that use a version numbering
 	convention that signals each version's stability and backward compatibility.
 
-<a id="design" ></a>
-## Design and development
+## Design and development {#design}
 
 Your module will be easier for developers to find and use if the functions and
 packages in it form a coherent whole. When you're designing a module's public
@@ -70,8 +68,7 @@ functions in the module while the module is still in development. For more
 information, see "Coding against an unpublished module" in [Module release and
 versioning workflow](release-workflow#unpublished).
 
-<a id="decentralized" ></a>
-## Decentralized publishing
+## Decentralized publishing {#decentralized}
 
 In Go, you publish your module by tagging its code in your repository to make it
 available for other developers to use. You don't need to push your module to a
@@ -88,13 +85,12 @@ along with the module version number you use to tag the module for release, to
 locate and download the module for its users.
 
 For more about source and publishing conventions and best practices, see
-[Managing module source](managing-source).
+[Managing module source](/doc/modules/managing-source).
 
 For step-by-step instructions on publishing a module, see [Publishing a
 module](publishing).
 
-<a id="discovery" ></a>
-## Package discovery
+## Package discovery {#discovery}
 
 After you've published your module and someone has fetched it with Go tools, it
 will become visible on the Go package discovery site at
@@ -107,8 +103,7 @@ runs the `go get` command to download its source code to compile with.
 For more about how developers find and use modules, see [Managing
 dependencies](managing-dependencies).
 
-<a id="versioning" ></a>
-## Versioning
+## Versioning {#versioning}
 
 As you revise and improve your module over time, you assign version numbers
 (based on the semantic versioning model) designed to signal each version's
@@ -121,4 +116,4 @@ For more on developing major version updates, see [Developing a major version
 update](major-version).
 
 For more about how you use the semantic versioning model for Go modules, see
-[Module version numbering](version-numbers).
+[Module version numbering](/doc/modules/version-numbers).