Update broken links (#3786)

Update broken links to aid in following links while perusing the
documentation. Closes #3778

I don't imagine I got every one of these right. Some 404s may be
reported due to permissions.

Using the lychee command in #3778, only the following link is reported
as not found, but it's just a permission issue:

```
[proposals/p1367.md]:
✗ [404] https://github.com/carbon-language/carbon-lang/settings/access | Failed: Network error: Not Found
```

I tried to get it down to as few as possible, partially so that future
link scans won't run into repeat errors.

---------

Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>

README.md

@@ -21,7 +21,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 <a href="docs/images/snippets.md#quicksort">
 <!--
 Edit snippet in docs/images/snippets.md and:
-https://drive.google.com/drive/folders/1-rsUjiya7dSZ87L8kpZmu3MZghRVxzLA
+https://drive.google.com/drive/folders/1QrBXiy_X74YsOueeC0IYlgyolWIhvusB
 -->
 <img src="docs/images/quicksort_snippet.svg" align="right" width="575"
      alt="Quicksort code in Carbon. Follow the link to read more.">

docs/design/README.md

@@ -3693,7 +3693,7 @@ tools. However, there is a large gap in programming models between the two
 languages, generally requiring a revision to the architecture. So, thus far the
 common pattern in the Rust community is to "rewrite it in Rust"
 ([1](https://deprogrammaticaipsum.com/the-great-rewriting-in-rust/),
-[2](https://unhandledexpression.com/rust/2017/07/10/why-you-should-actually-rewrite-it-in-rust.html),
+[2](https://web.archive.org/web/20230923033736/https://unhandledexpression.com/rust/2017/07/10/why-you-should-actually-rewrite-it-in-rust.html),
 [3](https://transitiontech.ca/random/RIIR)). Carbon's approach is to focus on
 migration from C++, including seamless interop, and then incrementally improve
 safety.

docs/design/generics/appendix-coherence.md

@@ -141,7 +141,7 @@ function from `SongHashArtistAndTitle` which returns a different hash value for
 
 **Background:** [This post](https://gist.github.com/nikomatsakis/1421744)
 discusses the hashtable problem in the context of Haskell, and
-[this 2011 Rust followup](https://mail.mozilla.org/pipermail/rust-dev/2011-December/001036.html)
+[this 2011 Rust followup](https://www.mail-archive.com/rust-dev@mozilla.org/msg01024.html)
 discusses how to detect problems at compile time.
 
 ## Rejected alternative: no orphan rule
@@ -191,7 +191,7 @@ body of the `SomethingWeirdHappens` function.
 
 This idea is discussed briefly in section 5.4 on separate compilation of WG21
 proposal n1848 for implementing "Indiana" C++0x concepts
-([1](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9526&rep=rep1&type=pdf),
+([1](https://citeseerx.ist.psu.edu/pdf/6e1398d22fd6a3e31aba2519d7a00a8f0d93e7e8),
 and [2](https://wg21.link/n1848)).
 
 This has some downsides:

docs/design/generics/details.md

@@ -3248,7 +3248,7 @@ parameter.
 
 **Comparison with other languages:** Both Swift
 ([1](https://www.swiftbysundell.com/tips/inferred-generic-type-constraints/),
-[2](https://github.com/apple/swift/blob/main/docs/Generics.rst#constraint-inference))
+[2](https://github.com/apple/swift/blob/main/docs/archive/Generics.rst#constraint-inference))
 and
 [Rust](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0b2d645bd205f24a7a6e2330d652c32e)
 support some form of this feature as part of their type inference (and

docs/design/generics/goals.md

@@ -314,7 +314,7 @@ possible instantiations, rather than with specific, concrete types.
 
 Some of this is likely unavoidable or too costly to avoid, as most existing
 checked generics systems
-[have undecidable aspects to their type system](https://3fx.ch/typing-is-hard.html),
+[have undecidable aspects to their type system](https://web.archive.org/web/20231223005655/https://3fx.ch/typing-is-hard.html),
 including [Rust](https://sdleffler.github.io/RustTypeSystemTuringComplete/) and
 Swift ([1](https://forums.swift.org/t/swift-type-checking-is-undecidable/39024),
 [2](https://forums.swift.org/t/termination-checking-for-type-substitution/64504),

docs/project/cpp_style_guide.md

@@ -92,7 +92,7 @@ these.
 -   Write `const` before the type when at the outer level: `const int N = 42;`.
 -   Only use line comments (with `//`, not `/* ... */`), on a line by
     themselves, except for
-    [argument name comments](https://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html#bugprone-argument-comment),
+    [argument name comments](https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argument-comment.html),
     [closing namespace comments](https://google.github.io/styleguide/cppguide.html#Namespaces),
     and similar structural comments. In particular, don't append comments about
     a line of code to the end of its line:

docs/project/faq.md

@@ -255,7 +255,7 @@ features, or
 maintaining a C++/Rust FFI may not be economically viable today (but it is an
 area of active research: [cxx](https://crates.io/crates/cxx),
 [autocxx](https://crates.io/crates/autocxx),
-[Crubit](https://github.com/google/crubit/blob/main/docs/design.md)).
+[Crubit](https://github.com/google/crubit/blob/main/docs/design/design.md)).
 
 The Carbon community is looking for a language that existing, large, monolithic
 C++ codebases can incrementally adopt and have a prospect of migrating away from

proposals/p0044.md

@@ -115,8 +115,9 @@ proposals, changes in approval from this doc may affect the evolution process.
 Explicit wording changes aren't outlined here because they are assumed to be
 part of executing this proposal rather than the substance of this proposal.
 
-For reference, a version of this proposal is also available in
-[GitHub](https://github.com/carbon-language/carbon-proposals/blob/d1946fab824742b4857fa74ffc1b9fe9af37375d/proposals/p0001.md).
+For reference, a version of this proposal is also available in GitHub (broken
+link:
+`https://github.com/carbon-language/carbon-proposals/blob/d1946fab824742b4857fa74ffc1b9fe9af37375d/proposals/p0001.md`).
 
 ## Proposal
 
@@ -589,10 +590,10 @@ Disadvantages:
     being replied to. This will generally make it infeasible to get context from
     emails.
 -   Comment threads sometimes make it unclear what's being replied to. for
-    example,
-    https://github.com/carbon-language/carbon-proposals/pull/5#discussion_r423401993
-    and
-    ttps://github.com/carbon-language/carbon-proposals/pull/5/files/a51ff951561accfb4aee403d7add6e8e69009ce1#r423401993
+    example, (broken link:
+    `https://github.com/carbon-language/carbon-proposals/pull/5#discussion_r423401993`)
+    and (broken link:
+    `https://github.com/carbon-language/carbon-proposals/pull/5/files/a51ff951561accfb4aee403d7add6e8e69009ce1#r423401993`)
     are equivalent, but the replied-to-comment is only visible in the file view.
     -   This may be particularly visible as an issue if high-level discussions
         are often not line-specific.

proposals/p0107.md

@@ -381,8 +381,8 @@ Disadvantages:
         as a distributable unit.
     -   [Rust](https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html),
         as a collection of crates.
-    -   [Swift](https://developer.apple.com/documentation/swift_packages), as a
-        distributable unit.
+    -   [Swift](https://developer.apple.com/documentation/packagedescription),
+        as a distributable unit.
 
 #### No association between the file system path and library/namespace
 

proposals/p0162.md

@@ -274,7 +274,7 @@ declaration:  "fn" identifier tuple return_type '{' statement_list '}'
 
 the `tuple` is used as a pattern to describe the parameters of the function. The
 grammar for function definitions does not currently include
-[implicit parameters](https://github.com/josh11b/carbon-lang/blob/generics-docs/docs/design/generics/terminology.md#implicit-parameter),
+[implicit parameters](/docs/design/generics/terminology.md#deduced-parameter),
 but the intent is to add them to the grammar in the future.
 
 In the rule for field declarations

proposals/p0196.md

@@ -95,8 +95,8 @@ safety for the purposes of security. We think this proposal provides that
 foundation.
 
 Note: The decision by the core team included a request to clarify the wording on
-build modes as described in
-[chandlerc's post](https://forums.carbon-lang.dev/t/request-for-decision-language-level-safety-strategy/196/6)
+build modes as described in chandlerc's post (broken link:
+`https://forums.carbon-lang.dev/t/request-for-decision-language-level-safety-strategy/196/6`)
 on the decision thread.
 
 ### Open questions

proposals/p0444.md

@@ -25,7 +25,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 ## Problem
 
-Right now we run our own [Discourse Forums](https://forums.carbon-lang.dev/).
+Right now we run our own Discourse Forums (broken link:
+`https://forums.carbon-lang.dev/`).
 [GitHub Discussions](https://docs.github.com/en/discussions) was recently
 released, and should be evaluated for appropriateness as a replacement.
 
@@ -39,8 +40,8 @@ repositories, as of March, it is
 Developers can
 [preview in carbon-lang](https://github.com/carbon-language/carbon-lang/discussions).
 
-[Discourse Forums](https://forums.carbon-lang.dev/) are currently used by
-Carbon. These run on a Google Cloud instance owned by Carbon team.
+Discourse Forums (broken link: `https://forums.carbon-lang.dev/`) are currently
+used by Carbon. These run on a Google Cloud instance owned by Carbon team.
 
 ## Proposal
 
@@ -106,10 +107,9 @@ investment into making a copy.
 
 #### Caveats
 
-The
-[contributor wiki](https://forums.carbon-lang.dev/t/contributor-directory-wiki/134/2)
-can be moved to
-[GitHub's wiki](https://github.com/carbon-language/carbon-lang/wiki).
+The contributor wiki (broken link:
+`https://forums.carbon-lang.dev/t/contributor-directory-wiki/134/2`) can be
+moved to [GitHub's wiki](https://github.com/carbon-language/carbon-lang/wiki).
 
 ## Rationale based on Carbon's goals
 

proposals/p1344.md

@@ -129,8 +129,8 @@ save, we suggest the following process:
 
 #### Archive your existing fork and clones
 
-1.  Go to the archived repository:
-    https://github.com/carbon-language/archived-carbon-lang
+1.  Go to the archived repository: (broken link:
+    `https://github.com/carbon-language/archived-carbon-lang`)
 
 2.  Fork this archived repository just like you normally would (into your
     _personal_ space). It is important to fork the `carbon-language` hosted

proposals/p2173.md

@@ -1096,9 +1096,10 @@ the approach taken by some other modern languages:
     programming language name) for the same reason, and similarly has a
     recursion limit.
 
-See also [Typing is Hard](https://3fx.ch/typing-is-hard.html), which lists
-similar information for a variety of other languages. Note that most languages
-listed have an undecidable type system.
+See also
+[Typing is Hard](https://web.archive.org/web/20231223005655/https://3fx.ch/typing-is-hard.html),
+which lists similar information for a variety of other languages. Note that most
+languages listed have an undecidable type system.
 
 Another candidate approach is to find a way to reduce the inputs to the
 type-checking step as a set of non-quantified equalities. The resulting system