Get rid of proc-macro-error (RUSTSEC-2024-0370 and syn version)

[domenicquirl]

So, someone filed an advisory against proc-macro-error for being unmaintained. Since validator-derive uses it, using validator made this show up in our CI. Tbh I'm somewhat sceptical as to the proposed solution of migrating to proc-macro-error-2, both because it is very recent and already had to release a bugfix for an oversight they made when forking the project, and because the primary reason to use proc-macro-error at all (to me, at least) is because it abstracts over stable vs. nightly diagnostic capabilities for proc macros, which the sequel doesn't do - they use a feature flag instead that needs to be set by the dependent.

That said, the original proc-macro-error due to its age is also one of the few crates in our dependency graph to still depend on syn version 1. Having to compile syn twice in an early stage of the build (since it is needed for basically all proc macros) is not great, and might honestly be a better / bigger reason to stop using proc-macro-error. As an alternative to switching to proc-macro-error2, here's a recent PR in utoipa (in particular the Diagnostics bit here, which GitHub likes to collapse by default). It's a bigger PR, but their macro API surface is also very large, so it should be less effort to do for validator-derive if that is wanted.

[domenicquirl]

There is also proc-macro2-diagnostics which is maintained and provides the same functionality (namely the nightly detection) of proc-macro-error.

[pvichivanives]

Update on this in case anyone is following: PR has been merged, awaiting new version release though.

[timleslie]

Just to set expectations, is there an ETA on a release? We have a low-urgency ticket to resolve the RUSTSEC issue in our repo, so it would be helpful if I could update that with a timeframe.

Thanks for all the work that goes into maintaining this crate, it's much appreciated 🙏

[Keats]

Probably next week when i get back from holiday