Refactor `get_first_two_components` to `get_next_component`.

Fixes the following behaviour of `parse_prefix`:
 - series of separator bytes in a prefix are correctly parsed as a single separator
 - device namespace prefixes correctly recognize both `\\` and `/` as separators

This improves how the `symbols` proc-macro handles errors.
If it finds an error in its input, the macro does not panic.
Instead, it still produces an output token stream. That token
stream will contain `compile_error!(...)` macro invocations.
This will still cause compilation to fail (which is what we want),
but it will prevent meaningless errors caused by the output not
containing symbols that the macro normally generates.

This solves a small (but annoying) problem. When you're editing
rustc_span/src/symbol.rs, and you get something wrong (dup
symbol name, misordered symbol), you want to get only the errors
that are relevant, not a burst of errors that are irrelevant.
This change also uses the correct Span when reporting errors,
so you get errors that point to the correct place in
rustc_span/src/symbol.rs where something is wrong.

This also adds several unit tests which test the `symbols` proc-macro.

This commit also makes it easy to run the `symbols` proc-macro
as an ordinary Cargo test. Just run `cargo test`. This makes it
easier to do development on the macro itself, such as running it
under a debugger.

This commit also uses the `Punctuated` type in `syn` for parsing
comma-separated lists, rather than doing it manually.

The output of the macro is not changed at all by this commit,
so rustc should be completely unchanged. This just improves
quality of life during development.

Refactor and fix `parse_prefix` on Windows

This PR is an extension of rust-lang#78692 as well as a general refactor of `parse_prefix`:

**Fixes**:
There are two errors in the current implementation of `parse_prefix`:

Firstly, in the current implementation only `\` is recognized as a separator character in device namespace prefixes. This behavior is only correct for verbatim paths; `"\\.\C:/foo"` should be parsed as `"C:"` instead of `"C:/foo"`.

Secondly, the current implementation only handles single separator characters. In non-verbatim paths a series of separator characters should be recognized as a single boundary, e.g. the UNC path `"\\localhost\\\\\\C$\foo"` should be parsed as `"\\localhost\\\\\\C$"` and then `UNC(server: "localhost", share: "C$")`, but currently it is not parsed at all, because it starts being parsed as `\\localhost\` and then has an invalid empty share location.

Paths like `"\\.\C:/foo"` and `"\\localhost\\\\\\C$\foo"` are valid on Windows, they are equivalent to just `"C:\foo"`.

**Refactoring**:
All uses of `&[u8]` within `parse_prefix` are extracted to helper functions and`&OsStr` is used instead. This reduces the number of places unsafe is used:
- `get_first_two_components` is adapted to the more general `parse_next_component` and used in more places
- code for parsing drive prefixes is extracted to `parse_drive`

…side-effects, r=dtolnay

doc(array,vec): add notes about side effects when empty-initializing

Copying some context from a conversation in the Rust discord:

* Both `vec![T; 0]` and `[T; 0]` are syntactically valid, and produce empty containers of their respective types

* Both *also* have side effects:

```rust
fn side_effect() -> String {
    println!("side effect!");

    "foo".into()
}

fn main() {
    println!("before!");

    let x = vec![side_effect(); 0];

    let y = [side_effect(); 0];

    println!("{:?}, {:?}", x, y);
}
```

produces:

```
before!
side effect!
side effect!
[], []
```

This PR just adds two small notes to each's documentation, warning users that side effects can occur.

I've also submitted a clippy proposal: rust-lang/rust-clippy#6439

… r=petrochenkov

Improve error handling in `symbols` proc-macro

This improves how the `symbols` proc-macro handles errors.
If it finds an error in its input, the macro does not panic.
Instead, it still produces an output token stream. That token
stream will contain `compile_error!(...)` macro invocations.
This will still cause compilation to fail (which is what we want),
but it will prevent meaningless errors caused by the output not
containing symbols that the macro normally generates.

This solves a small (but annoying) problem. When you're editing
rustc_span/src/symbol.rs, and you get something wrong (dup
symbol name, misordered symbol), you want to get only the errors
that are relevant, not a burst of errors that are irrelevant.
This change also uses the correct Span when reporting errors,
so you get errors that point to the correct place in
rustc_span/src/symbol.rs where something is wrong.

This also adds several unit tests which test the `symbols` proc-macro.

This commit also makes it easy to run the `symbols` proc-macro
as an ordinary Cargo test. Just run `cargo test`. This makes it
easier to do development on the macro itself, such as running it
under a debugger.

This commit also uses the `Punctuated` type in `syn` for parsing
comma-separated lists, rather than doing it manually.

The output of the macro is not changed at all by this commit,
so rustc should be completely unchanged. This just improves
quality of life during development.

Check the number of entries in UI test on tidy

This helps rust-lang#73494 to be resolved.

r? `@petrochenkov`

…on-panic, r=dtolnay

Fix overflow when converting ZST Vec to VecDeque

```rust
let v = vec![(); 100];
let queue = VecDeque::from(v);
println!("{:?}", queue);
```
This code will currently panic with a capacity overflow.
This PR resolves this issue and makes the code run fine.

Resolves rust-lang#78532

…ulacrum

BTreeMap: more expressive local variables in merge

r? `@Mark-Simulacrum`

… r=jyn514

Refactor test_lang_string_parse to make it clearer

Follows rust-lang#79454 (comment)

A small PR made to refactor a test in rustdoc that was becoming unwieldy.

`@rustbot` label T-rustdoc
r? `@jyn514`