add nightly and error_in_core features

to get an UserError::Variant from some other::ErrorType, we MUST be able to make a UserError::Variant directly from the other::ErrorType

otherwise, we can't construct Variant from ErrorType, as Variant has more fields.

(well, that could technically work if all of Variant's other fields are Default, but that seems error-prone)

in other words, make this valid:

use pisserror::Error;
use std::error::Error;

#[derive(Debug, Error)]
enum MyError {
    #[error]
    VariantWithFromField(#[from] std::io::Error),
    #[error("message has to be here: {_0}")]
    NormalVariant(i32),
}

yeah stop those please

preeeeetty sure the compilation error stems from the pattern matching, as the compiler is "expecting" unit variants

basically:

• make a struct that has all the data we collect
  • a struct with implementations like impl PissError<FromStep> would much-reduce the amount of args we pass around. (same with VariantType enum)
  • these impls can (and should) be in different files, modules of lib.rs
• run all the steps according to the type system using PhantomData
  • this might need some additional considerations, as the steps might become a little intermingled.
    • for example, From's outputs also influence how Error is implemented.
    • for now, that's fine. but what if they all rely on each other? design carefully!

users should be able to reference variant fields in their error messages

that's to account for other uses, like when constructing variants directly

the module would now contain:

// mod: variant

pub(fn) construct_variant_full_path(...) -> syn::Result<TokenStream2> {
    // do what we already do, but without the placeholders
    // ...
}

pub(crate) make_match_head(...) -> syn::Result<TokenStream2> {
    // use create_variant... here
    // make placeholders (either `(_, _, etc.)` or `{..}`
    // ...
}

otherwise, user might get some funky compile errors about not being able to implement the From trait for the same type twice

maybe just look for the attribute? otherwise there might be some weird way to tell. dear god i hope the attribute works

the errors are currently kinda confusing for users...

it should notice before trying to match on... no types.