[x/blog] content: add links from modules posts to modules docs

Adding to each blog post a link to modules-related documentation.

Change-Id: I0f82692b528c2fe910466f36303573ce1ec98ccd
Reviewed-on: https://go-review.googlesource.com/c/blog/+/290389
Run-TryBot: Steve Traut <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
X-Blog-Commit: 8b806c840d8a6d724d75db0d72e7e706b2c8810f

Author: Steve Traut

blog/content/migrating-to-go-modules.article

@@ -15,6 +15,10 @@ This post is part 2 in a series.
   - Part 4 — [Go Modules: v2 and Beyond](/v2-go-modules)
   - Part 5 — [Keeping Your Modules Compatible](/module-compatibility)
 
+**Note:** For documentation, see
+[Managing dependencies](https://golang.org/doc/modules/managing-dependencies)
+and [Developing and publishing modules](https://golang.org/doc/modules/developing).
+
 Go projects use a wide variety of dependency management strategies.
 [Vendoring](https://golang.org/cmd/go/#hdr-Vendor_Directories) tools such
 as [dep](https://github.com/golang/dep) and [glide](https://github.com/Masterminds/glide) are popular,

blog/content/module-compatibility.article

@@ -17,6 +17,9 @@ This post is part 5 in a series.
 - Part 4 — [Go Modules: v2 and Beyond](/v2-go-modules)
 - **Part 5 — Keeping Your Modules Compatible** (this post)
 
+**Note:** For documentation on developing modules, see
+[Developing and publishing modules](https://golang.org/doc/modules/developing).
+
 Your modules will evolve over time as you add new features, change behaviors, and reconsider parts of the module's public surface. As discussed in [Go Modules: v2 and Beyond](/v2-go-modules), breaking changes to a v1+ module must happen as part of a major version bump (or by adopting a new module path).
 
 However, releasing a new major version is hard on your users. They have to find the new version, learn a new API, and change their code. And some users may never update, meaning you have to maintain two versions for your code forever. So it is usually better to change your existing package in a compatible way.

blog/content/publishing-go-modules.article

@@ -15,6 +15,9 @@ This post is part 3 in a series.
   - Part 4 — [Go Modules: v2 and Beyond](/v2-go-modules)
   - Part 5 — [Keeping Your Modules Compatible](/module-compatibility)
 
+**Note:** For documentation on developing modules, see
+[Developing and publishing modules](https://golang.org/doc/modules/developing).
+
 This post discusses how to write and publish modules so other modules can depend
 on them.
 

blog/content/using-go-modules.article

@@ -17,6 +17,9 @@ This post is part 1 in a series.
   - Part 4 — [Go Modules: v2 and Beyond](/v2-go-modules)
   - Part 5 — [Keeping Your Modules Compatible](/module-compatibility)
 
+**Note:** For documentation on managing dependencies with modules, see
+[Managing dependencies](https://golang.org/doc/modules/managing-dependencies).
+
 Go 1.11 and 1.12 include preliminary
 [support for modules](https://golang.org/doc/go1.11#modules),
 Go’s

blog/content/v2-go-modules.article

@@ -17,6 +17,9 @@ This post is part 4 in a series.
   - **Part 4 — Go Modules: v2 and Beyond** (this post)
   - Part 5 — [Keeping Your Modules Compatible](/module-compatibility)
 
+**Note:** For documentation on developing modules, see
+[Developing and publishing modules](https://golang.org/doc/modules/developing).
+
 As a successful project matures and new requirements are added, past features
 and design decisions might stop making sense. Developers may want to integrate
 lessons they've learned by removing deprecated functions, renaming types, or