- Hopefully closes nushell#10120  

# Description

This PR adds a new config item, `error_style`. It will render errors in
a screen reader friendly mode when set to `"simple"`. This is done using
`miette`'s own `NarratableReportHandler`, which seamlessly replaces the
default one when needed.

Before:
```
Error: nu::shell::external_command

  × External command failed
   ╭─[entry #2:1:1]
 1 │ doesnt exist
   · ───┬──
   ·    ╰── executable was not found
   ╰────
  help: No such file or directory (os error 2)
```

After:
```
Error: External command failed
    Diagnostic severity: error
Begin snippet for entry #4 starting at line 1, column 1

snippet line 1: doesnt exist
    label at line 1, columns 1 to 6: executable was not found
diagnostic help: No such file or directory (os error 2)
diagnostic code: nu::shell::external_command

```

## Things to be determined

- ~Review naming. `errors.style` is not _that_ consistent with the rest
of the code. Menus use a `style` record, but table rendering mode is set
via `mode`.~ As it's a single config, we're using `error_style` for now.
- Should this kind of setting be toggable with one single parameter?
`accessibility.no_decorations` or similar, which would adjust the style
of both errors and tables accordingly.

# User-Facing Changes

No changes by default, errors will be rendered differently if
`error_style` is set to `simple`.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->

# After Submitting

There's a PR updating the docs over here
nushell/nushell.github.io#1026

…ushell#10430)

should close nushell#10406

# Description
when writing a script, with variables you try to `ls` or `open`, you
will get a "directory not found" error but the variable won't be
expanded and you won't be able to see which one of the variable was the
issue...

this PR adds this information to the error.

# User-Facing Changes
let's define a variable
```nushell
let does_not_exist = "i_do_not_exist_in_the_current_directory"
```
### before
```nushell
> open $does_not_exist
Error: nu::shell::directory_not_found

  × Directory not found
   ╭─[entry #7:1:1]
 1 │ open $does_not_exist
   ·      ───────┬───────
   ·             ╰── directory not found
   ╰────
```
```nushell
> ls $does_not_exist
Error: nu:🐚:directory_not_found

  × Directory not found
   ╭─[entry nushell#8:1:1]
 1 │ ls $does_not_exist
   ·    ───────┬───────
   ·           ╰── directory not found
   ╰────
```

### after
```nushell
> open $does_not_exist
Error: nu:🐚:directory_not_found

  × Directory not found
   ╭─[entry #3:1:1]
 1 │ open $does_not_exist
   ·      ───────┬───────
   ·             ╰── directory not found
   ╰────
  help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist
```
```nushell
> ls $does_not_exist
Error: nu:🐚:directory_not_found

  × Directory not found
   ╭─[entry #4:1:1]
 1 │ ls $does_not_exist
   ·    ───────┬───────
   ·           ╰── directory not found
   ╰────
  help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist
```

# Tests + Formatting
shouldn't harm anything 🤞 

# After Submitting

should close nushell#10549 

# Description
this PR is twofold
- uses `to nuon --raw` in the error messages to make sure nushell#10549 is
solved and makes a difference between `"1"` and `1`
- tries to introduce slightly better errors, i.e. by putting left /
right on new lines => this should hopefully help when the values become
a bit big 😋

# User-Facing Changes
the original issue:
```nushell
> assert equal {one:1 two:2} {one:"1" two:"2"}
Error:   × Assertion failed.
   ╭─[entry #3:1:1]
 1 │ assert equal {one:1 two:2} {one:"1" two:"2"}
   ·              ───────────────┬───────────────
   ·                             ╰── These are not equal.
        Left  : '{one: 1, two: 2}'
        Right : '{one: "1", two: "2"}'
   ╰────
```

a sample for all the assertions and their new messages
```nushell
> assert equal {one:1 two:2} {one:"1" two:"2"}
Error:   × Assertion failed.
   ╭─[entry #3:1:1]
 1 │ assert equal {one:1 two:2} {one:"1" two:"2"}
   ·              ───────────────┬───────────────
   ·                             ╰── These are not equal.
        Left  : '{one: 1, two: 2}'
        Right : '{one: "1", two: "2"}'
   ╰────
```
```nushell
> assert equal 1 2
Error:   × Assertion failed.
   ╭─[entry #4:1:1]
 1 │ assert equal 1 2
   ·              ─┬─
   ·               ╰── These are not equal.
        Left  : '1'
        Right : '2'
   ╰────
```
```nushell
> assert less 3 1
Error:   × Assertion failed.
   ╭─[entry #6:1:1]
 1 │ assert less 3 1
   ·             ─┬─
   ·              ╰── The condition *left < right* is not satisfied.
        Left  : '3'
        Right : '1'
   ╰────
```
```nushell
> assert less or equal 3 1
Error:   × Assertion failed.
   ╭─[entry #7:1:1]
 1 │ assert less or equal 3 1
   ·                      ─┬─
   ·                       ╰── The condition *left <= right* is not satisfied.
        Left  : '3'
        Right : '1'
   ╰────
```
```nushell
> assert greater 1 3
Error:   × Assertion failed.
   ╭─[entry nushell#8:1:1]
 1 │ assert greater 1 3
   ·                ─┬─
   ·                 ╰── The condition *left > right* is not satisfied.
        Left  : '1'
        Right : '3'
   ╰────
```
```nushell
> assert greater or equal 1 3
Error:   × Assertion failed.
   ╭─[entry nushell#9:1:1]
 1 │ assert greater or equal 1 3
   ·                         ─┬─
   ·                          ╰── The condition *left < right* is not satisfied.
        Left  : '1'
        Right : '3'
   ╰────
```
```nushell
> assert length [1 2 3] 2
Error:   × Assertion failed.
   ╭─[entry nushell#10:1:1]
 1 │ assert length [1 2 3] 2
   ·               ────┬────
   ·                   ╰── This does not have the correct length:
        value    : [1, 2, 3]
        length   : 3
        expected : 2
   ╰────
```
```nushell
> assert length [1 "2" 3] 2
Error:   × Assertion failed.
   ╭─[entry nushell#11:1:1]
 1 │ assert length [1 "2" 3] 2
   ·               ─────┬─────
   ·                    ╰── This does not have the correct length:
        value    : [1, "2", 3]
        length   : 3
        expected : 2
   ╰────
```
```nushell
> assert str contains "foo" "bar"
Error:   × Assertion failed.
   ╭─[entry nushell#13:1:1]
 1 │ assert str contains "foo" "bar"
   ·                     ─────┬─────
   ·                          ╰── This does not contain '($right)'.
        value: "foo"
   ╰────
```

# Tests + Formatting

# After Submitting

# Description
follow up to nushell#8529
cleaned up version of nushell#8892 

- the original syntax is okay
```nu
def okay [rec: record] {}
```
- you can now add type annotations for fields if you know
  them before hand
```nu
def okay [rec: record<name: string>] {}
```

- you can specify multiple fields
```nu
def okay [person: record<name: string age: int>] {}

# an optional comma is allowed
def okay [person: record<name: string, age: int>] {}
```

- if annotations are specified, any use of the command will be type
  checked against the specified type
```nu
def unwrap [result: record<ok: bool, value: any>] {}

unwrap {ok: 2, value: "value"}

# errors with

Error: nu::parser::type_mismatch

  × Type mismatch.
   ╭─[entry #4:1:1]
 1 │ unwrap {ok: 2, value: "value"}
   ·         ───────┬─────
   ·                    ╰── expected record<ok: bool, value: any>, found record<ok: int, value: string>
   ╰────
```
> here the error is in the `ok` field, since `any` is coerced into any
type
> as a result `unwrap {ok: true, value: "value"}` is okay

- the key must be a string, either quoted or unquoted
```nu
def err [rec: record<{}: list>] {}

# errors with
Error:
  × `record` type annotations key not string
   ╭─[entry #7:1:1]
 1 │ def unwrap [result: record<{}: bool, value: any>] {}
   ·                            ─┬
   ·                             ╰── must be a string
   ╰────
```

- a key doesn't have to have a type in which case it is assumed to be
`any`
```nu
def okay [person: record<name age>] {}

def okay [person: record<name: string age>] {}
```

- however, if you put a colon, you have to specify a type
```nu
def err [person: record<name: >] {}

# errors with
Error: nu::parser::parse_mismatch

  × Parse mismatch during operation.
   ╭─[entry nushell#12:1:1]
 1 │ def unwrap [res: record<name: >] { $res }
   ·                             ┬
   ·                             ╰── expected type after colon
   ╰────
```

# User-Facing Changes
**[BREAKING CHANGES]**
- this change adds a field to `SyntaxShape::Record` so any plugins that
used it will have to update and include the field. though if you are
unsure of the type the record expects, `SyntaxShape::Record(vec![])`
will suffice

…me (nushell#11384)

# Description

Fixes nushell#11382 

# User-Facing Changes
* before

```console
nushell/test (109f629) [✘?]
❯ open hello.md
hello
nushell/test (109f629) [✘?]
❯ ls hello.md | get size
╭───┬─────╮
│ 0 │ 6 B │
╰───┴─────╯
nushell/test (109f629) [✘?]
❯ open --raw hello.md | prepend "world" | save --raw --force hello.md
^C
nushell/test (109f629) [✘?]
❯ ls hello.md | get size
╭───┬─────────╮
│ 0 │ 2.8 GiB │
╰───┴─────────╯
```

* after

```console
nushell/test on  fix_save [✘!?⇡]
❯ open hello.md | prepend "hello" | save --force hello.md
nushell/test on  fix_save [✘!?⇡]
❯ open --raw hello.md | prepend "hello" | save --raw --force ../test/hello.md
Error:   × pipeline input and output are same file
   ╭─[entry #4:1:1]
 1 │ open --raw hello.md | prepend "hello" | save --raw --force ../test/hello.md
   ·                                                           ────────┬───────
   ·                                                                   ╰── can't save output to '/data/source/nushell/test/hello.md' while it's being reading
   ╰────
  help: you should change output path


nushell/test on  fix_save [✘!?⇡]
❯ open hello | prepend "hello" | save --force hello
Error:   × pipeline input and output are same file
   ╭─[entry #5:1:1]
 1 │ open hello | prepend "hello" | save --force hello
   ·                                            ──┬──
   ·                                              ╰── can't save output to '/data/source/nushell/test/hello' while it's being reading
   ╰────
  help: you should change output path
```

# Tests + Formatting
Make sure you've run and fixed any issues with these commands:
- [x] add `commands::save::save_same_file_with_extension`
- [x] add `commands::save::save_same_file_without_extension`
- [x] `cargo fmt --all -- --check` to check standard code formatting
(`cargo fmt --all` applies these changes)
- [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used`
to check that you're using the standard code style
- [x] `cargo test --workspace` to check that all tests pass (on Windows
make sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- [x] `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library

# After Submitting

# Description
Currently, when writing a record, if you don't give the value for a
field, the syntax error highlights the entire record instead of
pinpointing the issue. Here's some examples:

```nushell
> { a: 2, 3 } # Missing colon (and value)
Error: nu::parser::parse_mismatch

  × Parse mismatch during operation.
   ╭─[entry #2:1:1]
 1 │  { a: 2, 3 }
   ·  ─────┬─────
   ·       ╰── expected record
   ╰────

> { a: 2, 3: } # Missing value
Error: nu::parser::parse_mismatch

  × Parse mismatch during operation.
   ╭─[entry #3:1:1]
 1 │  { a: 2, 3: }
   ·  ──────┬─────
   ·        ╰── expected record
   ╰────

> { a: 2, 3 4 } # Missing colon
Error: nu::parser::parse_mismatch

  × Parse mismatch during operation.
   ╭─[entry #4:1:1]
 1 │  { a: 2, 3 4 }
   ·  ──────┬──────
   ·        ╰── expected record
   ╰────
```

In all of them, the entire record is highlighted red because an
`Expr::Garbage` is returned covering that whole span:


![image](https://github.com/nushell/nushell/assets/45539777/36660b50-23be-4353-b180-3f84eff3c220)

This PR is for highlighting only the part inside the record that could
not be parsed. If the record literal is big, an error message pointing
to the start of where the parser thinks things went wrong should help
people fix their code.

# User-Facing Changes
Below are screenshots of the new errors:

If there's a stray record key right before the record ends, it
highlights only that key and tells the user it expected a colon after
it:


![image](https://github.com/nushell/nushell/assets/45539777/94503256-8ea2-47dd-b69a-4b520c66f7b6)

If the record ends before the value for the last field was given, it
highlights the key and colon of that field and tells the user it
expected a value after the colon:


![image](https://github.com/nushell/nushell/assets/45539777/2f3837ec-3b35-4b81-8c57-706f8056ac04)

If there are two consecutive expressions without a colon between them,
it highlights everything from the second expression to the end of the
record and tells the user it expected a colon. I was tempted to add a
help message suggesting adding a colon in between, but that may not
always be the right thing to do.


![image](https://github.com/nushell/nushell/assets/45539777/1abaaaa8-1896-4909-bbb7-9a38cece5250)

# Tests + Formatting

# After Submitting