std::fmt: Various fixes and improvements to documentation

[EliasHolzmann]

This PR contains the following changes:

• Added argument index comments to examples for specifying precision

  The examples for specifying the precision have comments explaining which
  argument the specifier is referring to. However, for implicit positional
  arguments, the examples simply refer to "next arg". To simplify following the
  comments, "next arg" was supplemented with the actual resulting argument index.

• Fixed documentation for specifying precision via .*

  The documentation stated that in case of the syntax {<arg>:<spec>.*}, "the
  <arg> part refers to the value to print, and the precision must come in the
  input preceding <arg>". This is not correct: the part does indeed refer
  to the value to print, but the precision does not come in the input preciding
  arg, but in the next implicit input (as if specified with {}).

  Fixes std::fmt: Precision via asterisk does not fit documentation when using named or explicit positional arguments #96413.

• Fix the grammar documentation

  According to the grammar documented, the format specifier {: } should not be
  legal because of the whitespace it contains. However, in reality, this is
  perfectly fine because the actual implementation allows spaces before the
  closing brace. Fixes Format string parser does not fail on invalid input #71088.

  Also, the exact meaning of most of the terminal symbols was not specified, for
  example the meaning of identifier.

• Removed reference to Formatter::buf and other private fields

  Formatter::buf is not a public field and therefore isn't very helpful in user-
  facing documentation. Also, the other public fields of Formatter were removed
  during stabilization of std::fmt (4af3494) and can only be accessed via
  getters.

• Improved list of formatting macros

  Two improvements:

  1. write! can not only receive a io::Write, but also a fmt::Write as first argument.
  2. The description texts now contain links to the actual macros for easier
     navigation.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon.

Please see the contribution instructions for more information.

[joshtriplett]

Posted one minor nit; LGTM otherwise.

[joshtriplett]

@bors r+ rollup

[bors]

📌 Commit f3b86c3 has been approved by joshtriplett