blocker: relative paths involving parent directory in a workspace don't work when deploying to crates.io

[sam0x17]

Originally docify operated on workspace-relative paths, because this often makes the most sense when working in a large workspace. I switched this to be current-crate-relative because apparently when cargo deploys to crates.io, it completely isolates the current crate being compiled (even it if is part of a workspace) such that parent directories are inaccessible. This means any docify embeds that attempt to embed something that is relative to a parent directory of the current directory in a workspace will fail when you go to deploy to crates.io

This would be fine if we could cfg gate docify embed, but because we operate in #[doc = ..] position, this is also impossible because conditional compilation is impossible from that position. A possible workaround for this would be switching to #4 which uses an "outer attribute" approach that would allow gating docify embed such that they do not try to run during crates.io deploys. It has yet to be shown, however, whether this will still function correctly when docs.rs goes to deploy, since we've never gotten a build that far that uses parent directory relative paths.

The other potential workaround is to do a git integration as outlined in #14 and use this as a fallback for situations where the parent directory can't be accessed.

All attempts to detect whether we are cfg(doc) from within the docify::embed proc macro have also failed -- this is not detectable directly from the context of a proc macro, though this could change in the future if some of the proc macro diagnostics features get merged into stable.

[kianenigma]

Re-reading the issue again, I think the git integration is not extremely hard to do. It can use all the existing code when it comes to parsing, and just use an HTTP get instead of reading a local file as input.

@sam0x17 would be you down to implement this? This would be a huge unblocker, allowing us to publish https://paritytech.github.io/polkadot-sdk to crates.io, and get versioning in line with the polkadot-sdk stable release.

I will support the development of this with a onchain tip, in line with a /tip large polkadot-sdk tip.

[sam0x17]

Sure I think it would be quick enough that that would be sufficient, will see if I can do it tonight or this weekend