Add link to librustc_parse::lexer

Previously, if there were a module in scope with the same name as the
primitive, that would take precedence. Coupled with
https://github.com/rust-lang/rust/issues/58699, this made it impossible
to link to the primitive when that module was in scope.

This approach could be extended so that `struct@foo` would no longer resolve
to any type, etc. However, it could not be used for glob imports:

```rust
pub mod foo {
  pub struct Bar;
}

pub enum Bar {}
use foo::*;

// This is expected to link to `inner::Bar`, but instead it will link to the enum.
/// Link to [struct@Bar]
pub struct MyDocs;
```

The reason for this is that this change does not affect the resolution
algorithm of rustc_resolve at all. The only reason we could special-case
primitives is because we have a list of all possible primitives ahead of time.

This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags`
to be consistent with the other functions in the trait.

Since #73374 the rustc wrapper no longer configures debug assertions
based on RUSTC_DEBUG_ASSERTIONS environment variable.

This causes the components of FQN's to behave similarly to other links
in the contents of rustdoc-styled pages.

I (and I hope others at least in part) have found the prior design to be
somewhat confusing, as it is not clear (upon hovering) that the various
parts of the FQN are actually links that the user can navigate to.

In short, this patch makes links in the FQN have an underline when the
user hovers over them, more clearly indicating that they can be used for
navigation.
Signed-off-by: NKristofer Rye <kristofer.rye@gmail.com>

we used to erase the local just before we tried to read it for diagnostics

Co-authored-by: Nvarkor <github@varkor.com>

The thread that recovers the unique access to Arc inner value (e.g., drop
when ref-count strong reaches zero, successful try_unwrap), ensures that
other operations on Arc inner value happened before by synchronizing
with release operations performed when decrementing the reference counter.

When try_unwrap succeeds, the current thread recovers the unique access
to Arc inner value, so release is unnecessary.

- Add newline to provide concise module summary
- Add wikipedia link
- Italicize O notation

The current plan is that submodule tracks the `release` branch of
rust-analyzer, which is updated once a week.

rust-analyzer is a workspace (with a virtual manifest), the actual
binary is provide by `crates/rust-analyzer` package.

Note that we intentionally don't add rust-analyzer to `Kind::Test`,
for two reasons.

*First*, at the moment rust-analyzer's test suite does a couple of
things which might not work in the context of rust repository. For
example, it shells out directly to `rustup` and `rustfmt`. So, making
this work requires non-trivial efforts.

*Second*, it seems unlikely that running tests in rust-lang/rust repo
would provide any additional guarantees. rust-analyzer builds with
stable and does not depend on the specifics of the compiler, so
changes to compiler can't break ra, unless they break stability
guarantee. Additionally, rust-analyzer itself is gated on bors, so we
are pretty confident that test suite passes.