Make syn2 and syn3 not mutually exclusive

[datdenkikniet]

This is a (bad) attempt at fixing #28.

The thing that makes fixing this tricky is that syn2::parse::Parse and syn3::parse::Parse have overlapping implementations (e.g. both are implemented proc_macro2::Ident).

I don't really understand the manyhow internals, so am having a hard time figuring out which types $n can actually have in __macro_handler (is it a restricted set? Or are all syn2::parse::Parse/syn3::parse::Parse fair game?). If it is a restricted set, we should be able to definitively state whether this change is breaking: iff $n can be of a type that implements both syn2::parse::Parse and syn3::parse::Parse, this solution will not work.

ETA: it seems that this passes CI (see: datdenkikniet#1), so am un-drafting it.

[datdenkikniet]

OK, I've double-checked and it seems that $n can be any type. There are a few options/alternatives:

1. Keep the status-quo, make stuff not compile if/when proc-macros using manyhow start upgrading their syn dependencies from 2 to 3.
2. Merge this change, and stop supporting types that are both syn2::Parse and syn3::Parse as input to the macro_rules! implementations (from what I can tell: all applicable proc_macro2 types do this). However, we'll need an "is proc_macro2" check that is always active to prevent this from only failing to compile if both syn2 and syn3 are activated.
3. Require that the macro_rules! versions explicitly specify the crate to call parse2 from to avoid the trait + macro-hygiene all together. The proc-macro most likely doesn't need syntax changes: it can just emit syn as the crate name (and/or take an optional argument to specify it). Something like attribute!(syn, ...).
4. Separate major versions of manyhow for different syn major versions.

[datdenkikniet]

On further thought, this PR is a terrible fit: it just works around a fairly fundamental problem that I don't think can or should be remedied without implementing solution 3 that I propose above.