Attribute proc-macro follow up

[daxpedda]

Fixes #35.

I added a note in the README, but noticed that actually setting the path can produce some pretty unexpected behavior.

What do you think of adding an error if a derive_where::derive_where is found as not the first attribute? This isn't bulletproof of course because derive_where_export::derive_where could still remain undetected.

[daxpedda]

I just stumbled on an idea. We could leave a marker to signify that this item was already handled by a derive-where macro. We control the outputted item, so we could just add a comment: /* derive_where was here! */. If that comment was found by a follow up proc macro attribute it could error out.

[daxpedda]

Actually I couldn't find a way to mark the item. Comments aren't represented in the AST apparently, only doc comments, and I can't figure out how to make a "hidden" doc comment, so it doesn't show up in the documentation by the user.

The other idea I had while writing this was to introduce another attribute called derive_where_visited, but it actually hits the same problem, it won't work without proper qualifying it unless it's imported by the user. We also don't have $crate for proc macros, see rust-lang/rust#54363, which would solve that problem.

So I think the best would be to introduce a hidden doc comment or find some other attribute that can be no-op. If you come up with anything hit me.

[daxpedda]

To solve the problem with derive_where_visited we could also introduce a crate setting: #[derive_where_::derive_where(crate = "derive_where_"; Clone; T)]?

[daxpedda]

Let's figure out #37 before we decide to merge this.

[ModProg]

Looks good AFAICT. If attribute macros on fields were introduced, we could circumvent all of this, probably.

[daxpedda]

Alright, re-based and adjusted to the latest changes we did in #37.

[daxpedda]

Build failed because of some connection issue, would be nice if you re-start it @ModProg.