Fix date-check comment formatting (#1066)

I realized that the format I had been previously using for date-checks

    (as of January 2021 <!-- date: 2021-01 -->)

left a space before the closing parenthesis in the rendered output,
which looks weird.

I could fix this by removing the space between `2021` and `<!-- ...`,
but that looks weird in the source. So I ended up deciding on changing
it to

    (as of <!-- date: 2021-01 --> January 2021)

Author: camelid

src/diagnostics.md

@@ -596,7 +596,7 @@ declare_lint! {
 
 If you need a combination of options that's not supported by the `declare_lint!`
 macro, you can always define your own static with a type of `&Lint` but this is
-(as of January 2021 <!-- date: 2021-01 -->) linted against in the compiler tree.
+(as of <!-- date: 2021-01 --> January 2021) linted against in the compiler tree.
 
 <a id="future-incompatible"></a>
 ####  Guidelines for creating a future incompatibility lint

src/git.md

@@ -147,7 +147,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 These changes are not changes to files: they are changes to submodules (more on
 this [later](#git-submodules)). To get rid of those, run `git submodule update`
 (or run any `x.py` command, which will automatically update the submodules).
-Note that there is (as of January 2021 <!-- date: 2021-01 -->) a bug if you use
+Note that there is (as of <!-- date: 2021-01 --> January 2021) a bug if you use
 worktrees, submodules, and x.py in a commit hook.  If you run into an error
 like:
 

src/llvm-coverage-instrumentation.md

@@ -221,8 +221,8 @@ properly-configured variables in LLVM IR, according to very specific
 details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format]
 (Version 4).[^llvm-and-covmap-versions]
 
-[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021 <!-- date:
-2021-01 -->) supports _LLVM Coverage Mapping Format_ Version 4 (the most
+[^llvm-and-covmap-versions]: The Rust compiler (as of <!-- date: 2021-01 -->
+January 2021) supports _LLVM Coverage Mapping Format_ Version 4 (the most
 up-to-date version of the format, at the time of this writing) for improved
 compatibility with other LLVM-based compilers (like _Clang_), and to take
 advantage of some format optimizations. Version 4 was introduced in _LLVM 11_,

src/opaque-types-type-alias-impl-trait.md

@@ -14,8 +14,8 @@ This declares an opaque type named `Foo`, of which the only information is that
 it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`,
 but nothing else (regardless of whether it implements any other traits).
 
-Since there needs to be a concrete background type, you can (as of January 2021
-<!-- date: 2021-01 -->) express that type by using the opaque type in a
+Since there needs to be a concrete background type, you can (as of <!-- date:
+2021-01 --> January 2021) express that type by using the opaque type in a
 "defining use site".
 
 ```rust,ignore

src/query.md

@@ -1,7 +1,7 @@
 # Queries: demand-driven compilation
 
 As described in [the high-level overview of the compiler][hl], the Rust compiler
-is still (as of January 2021 <!-- date: 2021-01 -->) transitioning from a
+is still (as of <!-- date: 2021-01 --> January 2021) transitioning from a
 traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query
 System is the key to our new demand-driven organization.** The idea is pretty
 simple. You have various queries that compute things about the input – for

src/traits/chalk.md

@@ -1,7 +1,7 @@
 # Chalk-based trait solving
 
-[Chalk][chalk] is an experimental trait solver for Rust that is (as of January
-2021 <!-- date: 2021-01 -->) under development by the [Traits Working
+[Chalk][chalk] is an experimental trait solver for Rust that is (as of <!--
+date: 2021-01 --> January 2021) under development by the [Traits Working
 Group][wg]. Its goal is to enable a lot of trait system features and bug fixes
 that are hard to implement (e.g. GATs or specialization). If you would like to
 help in hacking on the new solver, you will find instructions for getting

src/type-inference.md

@@ -72,7 +72,7 @@ inference works, or perhaps this blog post on
 [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/
 
 All told, the inference context stores four kinds of inference variables (as of
-January 2018 <!-- date: 2018-01 -->):
+<!-- date: 2018-01 --> January 2018):
 
 - Type variables, which come in three varieties:
   - General type variables (the most common). These can be unified with any