Refactor the derive crate

[ascjones]

As raised in #61 (review), it is less than ideal we have to pass around the crate names to all the functions.

Originally the proc macro was very small so could justify being a few functions, but now it is becoming unwieldy and there is the above mentioned problem of shared global state.

One approach would be to separate the process into 2 steps parse -> Intermediate Representation -> expand which is a common pattern in proc macros.

[Robbepop]

You might be thinking about using the https://crates.io/crates/synstructure crate for the refactoring of the derive macros.
In ink! we are using this crate and it really simplifies a lot and was also a great learning experience since it heavily simplifies the concepts behind the syntactic structures behind Rust code.

[ascjones]

I did experiment with that and decided (at the time) that it wasn't suitable because it was more aimed at generating derived impls for type instances, and we have a static method so no instance to match against.

However I could be wrong and it is certainly worth revisiting.

[Robbepop]

I did experiment with that and decided (at the time) that it wasn't suitable because it was more aimed at generating derived impls for type instances, and we have a static method so no instance to match against.

However I could be wrong and it is certainly worth revisiting.

It is a very flexible crate, yet also introduces further complexity because you have to understand how it is meant to be used. So please take my thoughts as reminder that this crate exists and might do a good job here, not as suggestion. ;)

[ascjones]

I will definitely look again at it - I do like what I have seen where you have used it.