Change the wording of section references to what i prefer

Nostarch changed these to be "the section X" rather than "the X section"
but in the actual print version it turns into "X on page Y" so we can
diverge from nostarch because it diverges anyway.

src/ch07-00-managing-growing-projects-with-packages-crates-and-modules.md

@@ -13,7 +13,7 @@ optionally one library crate. As a package grows, you can extract parts into
 separate crates that become external dependencies. This chapter covers all
 these techniques. For very large projects of a set of interrelated packages
 that evolve together, Cargo provides *workspaces*, which we’ll cover in the
-section [“Cargo Workspaces”][workspaces]<!-- ignore --> in Chapter 14.
+[“Cargo Workspaces”][workspaces]<!-- ignore --> section in Chapter 14.
 
 In addition to grouping functionality, encapsulating implementation details
 lets you reuse code at a higher level: once you’ve implemented an operation,

src/ch07-01-packages-and-crates.md

@@ -3,10 +3,10 @@
 The first parts of the module system we’ll cover are *packages* and *crates*. A
 *crate* is a binary or library. The *crate root* is a source file that the Rust
 compiler starts from and makes up the root module of your crate (we’ll explain
-modules in depth in the section [“Defining Modules to Control Scope and
-Privacy”][modules]<!-- ignore -->). A *package* is one or more crates that
-provide a set of functionality. A package contains a *Cargo.toml* file that
-describes how to build those crates.
+modules in depth in the [“Defining Modules to Control Scope and
+Privacy”][modules]<!-- ignore -->) section. A *package* is one or more crates
+that provide a set of functionality. A package contains a *Cargo.toml* file
+that describes how to build those crates.
 
 Several rules determine what a package can contain. A package *must* contain
 zero or one library crates, and no more. It can contain as many binary crates

src/ch07-04-bringing-paths-into-scope-with-the-use-keyword.md

@@ -258,9 +258,9 @@ available to our project.
 
 Then, to bring `rand` definitions into the scope of our package, we added a
 `use` line starting with the name of the package, `rand`, and listing the items
-we wanted to bring into scope. Recall that in the section [“Generating a Random
-Number”][rand]<!-- ignore --> in Chapter 2, we brought the `Rng` trait into
-scope and called the `rand::thread_rng` function:
+we wanted to bring into scope. Recall that in the [“Generating a Random
+Number”][rand]<!-- ignore --> section in Chapter 2, we brought the `Rng` trait
+into scope and called the `rand::thread_rng` function:
 
 ```rust,ignore
 use rand::Rng;
@@ -366,11 +366,11 @@ harder to tell what names are in scope and where a name used in your program
 was defined.
 
 The glob operator is often used when testing to bring everything under test
-into the `tests` module; we’ll talk about that in the section [“How to Write
-Tests”][writing-tests]<!-- ignore --> in Chapter 11. The glob operator is also
-sometimes used as part of the prelude pattern: see [the standard library
-documentation](../std/prelude/index.html#other-preludes)<!-- ignore --> for
-more information on that pattern.
+into the `tests` module; we’ll talk about that in the [“How to Write
+Tests”][writing-tests]<!-- ignore --> section in Chapter 11. The glob operator
+is also sometimes used as part of the prelude pattern: see [the standard
+library documentation](../std/prelude/index.html#other-preludes)<!-- ignore -->
+for more information on that pattern.
 
 [rand]: ch02-00-guessing-game-tutorial.html#generating-a-random-number
 [writing-tests]: ch11-01-writing-tests.html#how-to-write-tests