Support raw-identifier fields in format strings

[ninevra]

Fixes #96 by stripping the "r#" prefix from format variables.

Background

Previously, given a type like

#[derive(Error, Debug)]
#[error("a raw ident: {r#reserved}")]`
struct RawError {
    r#reserved: String,
}

thiserror would output something like

// ...
Self { r#reserved } = self;
write!("a raw ident: {r#reserved}", r#reserved = r#reserved);
// ...

This would fail during write!() expansion because the character # isn't allowed in named format!() parameters.

Proposed solution

This PR replaces the r# prefix with raw_field_ when generating named parameters, producing output like

// ...
Self { r#reserved } = self;
write!("a raw ident: {raw_field_reserved}", raw_field_reserved = r#reserved);
// ...

Caveat: Possible name collision

The generated named parameters could collide with user-defined named parameters. For example, the following compiles but produces potentially-unexpected output:

#[derive(Error, Debug)]
#[error("a raw ident: {r#reserved}; and a named parameter: {raw_field_reserved}", raw_field_reserved = "some value")]`
struct RawError {
    r#reserved: String,
}

println!("{}", RawError { r#reserved: "some other value" });

This kind of collision is already possible in thiserror. Existing code maps tuple fields to named parameters of the form field_0. These collisions could be avoided by instead mapping field references to anonymous parameters ({}), which is actually what the documentation claims is done already; however, I think that's outside the scope of this PR.

Further work

A similar but disjoint issue: thiserror assumes all user-defined named parameters are valid identifiers, and panics if it encounters an exception. format!() itself does not require this. I think fixing this is outside the scope of this PR.

[ninevra]

Although this line does use unwrap(), it should only panic in the same cases as Ident::new() already does, i.e. invalid identifiers.

[dtolnay]

Thanks!