Fix misuse of *usage* in rule identifiers

In the prior commit, we fixed prose occurrences of *usage*.  The same
reasoning applies to the rule identifiers.

These rules describe where the language permits a construct to appear.
On the surface, that may seem to be a kind of pattern of use, but it's
not (in the sense implied by *usage*), and ultimately *use* is still
the right word.  The word *usage* describes conventions and customs --
i.e., *customary* patterns of use.  It describes how a community uses
something and how that varies, e.g., across regions.

That's not what we're doing here.  We're not describing better or
worse Rust idioms.  There's no "nonstandard usage" of Rust grammatical
constructs -- that's not what we're defining, at least.

Let's fix each rule identifier to use `use` instead.

(None of these identifiers were referenced elsewhere in
the Reference.)

src/items/generics.md

diff --git a/src/items/generics.md b/src/items/generics.md
index a31f513..06eb2b6 100644
--- a/src/items/generics.md
+++ b/src/items/generics.md
@@ -56,7 +56,7 @@
 r[items.generics.const.allowed-types]
 The only allowed types of const parameters are `u8`, `u16`, `u32`, `u64`, `u128`, `usize`, `i8`, `i16`, `i32`, `i64`, `i128`, `isize`, `char` and `bool`.
 
-r[items.generics.const.usage]
+r[items.generics.const.use]
 Const parameters can be used anywhere a [const item] can be used, with the exception that when used in a [type] or [array repeat expression], it must be standalone (as described below). That is, they are allowed in the following places:
 
 1. As an applied const to any type which forms a part of the signature of the item in question.

src/items/implementations.md

diff --git a/src/items/implementations.md b/src/items/implementations.md
index a97af7e..12764a4 100644
--- a/src/items/implementations.md
+++ b/src/items/implementations.md
@@ -188,7 +188,7 @@
 }
 ```
 
-r[items.impl.generics.usage]
+r[items.impl.generics.use]
 Generic parameters *constrain* an implementation if the parameter appears at least once in one of:
 
 * The implemented trait, if it has one

src/items/unions.md

diff --git a/src/items/unions.md b/src/items/unions.md
index 4551682..c330b03 100644
--- a/src/items/unions.md
+++ b/src/items/unions.md
@@ -180,7 +180,7 @@
 }
 ```
 
-r[items.union.ref.usage]
+r[items.union.ref.use]
 As you could see, in many aspects (except for layouts, safety, and ownership) unions behave exactly like structs, largely as a consequence of inheriting their syntactic shape from structs. This is also true for many unmentioned aspects of Rust language (such as privacy, name resolution, type inference, generics, trait implementations, inherent implementations, coherence, pattern checking, etc etc etc).
 
 [`transmute`]: std::mem::transmute

src/patterns.md

diff --git a/src/patterns.md b/src/patterns.md
index feb3aa7..f30d9d7 100644
--- a/src/patterns.md
+++ b/src/patterns.md
@@ -61,7 +61,7 @@
 }
 ```
 
-r[patterns.usage]
+r[patterns.use]
 Patterns are used in:
 
 r[patterns.let]

src/types/boolean.md

diff --git a/src/types/boolean.md b/src/types/boolean.md
index 1420d03..b02abfa 100644
--- a/src/types/boolean.md
+++ b/src/types/boolean.md
@@ -20,13 +20,13 @@
 r[type.bool.repr]
 The value false has the bit pattern `0x00` and the value true has the bit pattern `0x01`. It is [undefined behavior] for an object with the boolean type to have any other bit pattern.
 
-r[type.bool.usage]
+r[type.bool.use]
 The boolean type is the type of many operands in various [expressions]:
 
-r[type.bool.usage-condition]
+r[type.bool.use-in-condition]
 * The condition operand in [if expressions] and [while expressions]
 
-r[type.bool.usage-lazy-operator]
+r[type.bool.use-in-lazy-operator]
 * The operands in [lazy boolean operator expressions][lazy]
 
 > [!NOTE]

src/visibility-and-privacy.md

diff --git a/src/visibility-and-privacy.md b/src/visibility-and-privacy.md
index d5d7b64..656b8a1 100644
--- a/src/visibility-and-privacy.md
+++ b/src/visibility-and-privacy.md
@@ -56,7 +56,7 @@
 
 In the second case, it mentions that a private item "can be accessed" by the current module and its descendants, but the exact meaning of accessing an item depends on what the item is.
 
-r[vis.usage]
+r[vis.use]
 Accessing a module, for example, would mean looking inside of it (to import more items). On the other hand, accessing a function would mean that it is invoked. Additionally, path expressions and import statements are considered to access an item in the sense that the import/expression is only valid if the destination is in the current visibility scope.
 
 Here's an example of a program which exemplifies the three cases outlined above: