Format all Markdown files with dprint (#1157)

This is the result of running `dprint fmt` after removing `src/` from
the list of excluded directories.

This also reformats the Rust code: we might want to tweak this a bit in
the future since some of the changes removes the hand-formatting. Of
course, this formatting can be seen as a mis-feature, so maybe this is
good overall.

Thanks to mdbook-i18n-helpers 0.2, the POT file is nearly unchanged
after this, meaning that all existing translations remain valid! A few
messages were changed because of stray whitespace characters:

     msgid ""
     "Slices always borrow from another object. In this example, `a` has to remain "
    -"'alive' (in scope) for at least as long as our slice. "
    +"'alive' (in scope) for at least as long as our slice."
     msgstr ""

The formatting is enforced in CI and we will have to see how annoying
this is in practice for the many contributors. If it becomes annoying,
we should look into fixing dprint/check#11 so that `dprint` can annotate
the lines that need fixing directly, then I think we can consider more
strict formatting checks.

I added more customization to `rustfmt.toml`. This is to better emulate
the dense style used in the course:

- `max_width = 85` allows lines to take up the full width available in
our code blocks (when taking margins and the line numbers into account).
- `wrap_comments = true` ensures that we don't show very long comments
in the code examples. I edited some comments to shorten them and avoid
unnecessary line breaks — please trim other unnecessarily long comments
when you see them! Remember we're writing code for slides 😄
- `use_small_heuristics = "Max"` allows for things like struct literals
and if-statements to take up the full line width configured above.

The formatting settings apply to all our Rust code right now — I think
we could improve this with https://github.com/dprint/dprint/issues/711
which lets us add per-directory `dprint` configuration files. However,
the `inherit: true` setting is not yet implemented (as far as I can
tell), so a nested configuration file will have to copy most or all of
the top-level file.

src/iterators/exercise.md

@@ -11,7 +11,6 @@ Copy the following code to <https://play.rust-lang.org/> and make the tests
 pass. Use an iterator expression and `collect` the result to construct the
 return value.
 
-
 ```rust
 {{#include exercise.rs:offset_differences}}
     unimplemented!()
@@ -19,4 +18,5 @@ return value.
 
 {{#include exercise.rs:unit-tests}}
 ```
+
 [1]: https://doc.rust-lang.org/std/iter/trait.Iterator.html

src/iterators/exercise.rs

@@ -16,8 +16,8 @@
 
 // ANCHOR: solution
 // ANCHOR: offset_differences
-/// Calculate the differences between elements of `values` offset by `offset`, wrapping
-/// around from the end of `values` to the beginning.
+/// Calculate the differences between elements of `values` offset by `offset`,
+/// wrapping around from the end of `values` to the beginning.
 ///
 /// Element `n` of the result is `values[(n+offset)%len] - values[n]`.
 fn offset_differences<N>(offset: usize, values: Vec<N>) -> Vec<N>

src/iterators/fromiterator.md

@@ -9,10 +9,7 @@ minutes: 5
 ```rust,editable
 fn main() {
     let primes = vec![2, 3, 5, 7];
-    let prime_squares = primes
-        .into_iter()
-        .map(|prime| prime * prime)
-        .collect::<Vec<_>>();
+    let prime_squares = primes.into_iter().map(|p| p * p).collect::<Vec<_>>();
     println!("prime_squares: {prime_squares:?}");
 }
 ```
@@ -30,11 +27,10 @@ where
 
 There are two ways to specify `B` for this method:
 
- * With the "turbofish": `some_iterator.collect::<COLLECTION_TYPE>()`, as
-   shown. The `_` shorthand used here lets Rust infer the type of the `Vec`
-   elements. 
- * With type inference: `let prime_squares: Vec<_> =
-   some_iterator.collect()`. Rewrite the example to use this form.
+- With the "turbofish": `some_iterator.collect::<COLLECTION_TYPE>()`, as shown.
+  The `_` shorthand used here lets Rust infer the type of the `Vec` elements.
+- With type inference: `let prime_squares: Vec<_> = some_iterator.collect()`.
+  Rewrite the example to use this form.
 
 There are basic implementations of `FromIterator` for `Vec`, `HashMap`, etc.
 There are also more specialized implementations which let you do cool things

src/iterators/intoiterator.md

@@ -48,10 +48,7 @@ impl Iterator for GridIter {
 }
 
 fn main() {
-    let grid = Grid {
-        x_coords: vec![3, 5, 7, 9],
-        y_coords: vec![10, 20, 30, 40],
-    };
+    let grid = Grid { x_coords: vec![3, 5, 7, 9], y_coords: vec![10, 20, 30, 40] };
     for (x, y) in grid {
         println!("point = {x}, {y}");
     }
@@ -63,8 +60,8 @@ fn main() {
 Click through to the docs for `IntoIterator`. Every implementation of
 `IntoIterator` must declare two types:
 
-* `Item`: the type to iterate over, such as `i8`,
-* `IntoIter`: the `Iterator` type returned by the `into_iter` method.
+- `Item`: the type to iterate over, such as `i8`,
+- `IntoIter`: the `Iterator` type returned by the `into_iter` method.
 
 Note that `IntoIter` and `Item` are linked: the iterator must have the same
 `Item` type, which means that it returns `Option<Item>`

src/iterators/iterator.md

@@ -5,11 +5,12 @@ minutes: 5
 <!-- NOTES:
 The Iterator trait and basic usage
 -->
+
 # `Iterator`
 
 The [`Iterator`][1] trait supports iterating over values in a collection. It
-requires a `next` method and provides lots of methods. Many standard library types
-implement `Iterator`, and you can implement it yourself, too:
+requires a `next` method and provides lots of methods. Many standard library
+types implement `Iterator`, and you can implement it yourself, too:
 
 ```rust,editable
 struct Fibonacci {
@@ -38,15 +39,15 @@ fn main() {
 
 <details>
 
-* The `Iterator` trait implements many common functional programming operations over collections
-  (e.g. `map`, `filter`, `reduce`, etc). This is the trait where you can find all the documentation
-  about them. In Rust these functions should produce the code as efficient as equivalent imperative
-  implementations.
+- The `Iterator` trait implements many common functional programming operations
+  over collections (e.g. `map`, `filter`, `reduce`, etc). This is the trait
+  where you can find all the documentation about them. In Rust these functions
+  should produce the code as efficient as equivalent imperative implementations.
 
-* `IntoIterator` is the trait that makes for loops work. It is implemented by collection types such as
-  `Vec<T>` and references to them such as `&Vec<T>` and `&[T]`. Ranges also implement it. This is why
-  you can iterate over a vector with `for i in some_vec { .. }` but
-  `some_vec.next()` doesn't exist.
+- `IntoIterator` is the trait that makes for loops work. It is implemented by
+  collection types such as `Vec<T>` and references to them such as `&Vec<T>` and
+  `&[T]`. Ranges also implement it. This is why you can iterate over a vector
+  with `for i in some_vec { .. }` but `some_vec.next()` doesn't exist.
 
 </details>