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.)

Author: traviscross

src/items/generics.md

@@ -56,7 +56,7 @@ The const identifier introduces a name in the [value namespace] for the constant
 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

@@ -188,7 +188,7 @@ impl Seq<bool> for u32 {
 }
 ```
 
-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

@@ -180,7 +180,7 @@ fn test() {
 }
 ```
 
-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

@@ -61,7 +61,7 @@ if let
 }
 ```
 
-r[patterns.usage]
+r[patterns.use]
 Patterns are used in:
 
 r[patterns.let]

src/types/boolean.md

@@ -20,13 +20,13 @@ An object with the boolean type has a [size and alignment] of 1 each.
 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

@@ -56,7 +56,7 @@ These two cases are surprisingly powerful for creating module hierarchies exposi
 
 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: