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.