Fix for ObsidianOpen not working with links

[shakesbeare]

Potential fix for #107

Summary

This change modifies the ObsidianOpen command to additionally check if Plenary's make_relative method fails by attempting to find the vault root directory in the path after the call to make_relative. If the vault root directory is found, the new implementation simply substitutes out everything up to and including the root directory in an attempt to make the path work.

Limitations

• This method will not work if the link which the vault is behind is directly to the vault and the name of the link does not match the name of the vault. In this case, both make_relative and my proposed fix will fail. To fix this would require actually detecting if the vault is behind a link and following it in order to initialize the vault path as its absolute version from the get go. The only way I could find to accomplish this was to use an external library for Lua, which I figured might not be ideal to require as a dependency for what is really a bit of a niche bug.
• This will also fail if the user happens to keep their note in a subfolder of their vault which shares the same name as the vault itself. This seemed like a more unlikely scenario than someone wanting their vault directory to be behind a link, which would justify the change.
• I believe I have accounted for Windows paths as well, though I imagine that links will look and function differently in Windows. This change may not work for Windows users as a result. That said, it shouldn't break any existing instances that were already working.

[epwalsh]

Thanks for working on this @shakesbeare! Could you just add some comments in the code to explain what's going on and why we have to do that?

[shakesbeare]

@epwalsh Done! Plus, I added a Changelog entry. I was toying with the idea of mentioning the issue somewhere in the README, but wasn't sure how to phrase it given that it should work properly for most everyone now. Thoughts?

[epwalsh]

I was toying with the idea of mentioning the issue somewhere in the README, but wasn't sure how to phrase it given that it should work properly for most everyone now.

I like the idea of adding a "## Known issues" section, and I think saying something like "this is edge case that won't affect most people" is fine.

[epwalsh]

LGTM!

I'll hold off on merging until you let me know if you want to add something to the README about known issues.

[shakesbeare]

@epwalsh Went ahead and added the README section