QoL improvements for dealing with IPFS URLs for files in directories

[roachcord3]

This is related to #981 and #1312, but is more complicated and could be built as an iteration on top of #1312, so I figured it would be better to split it out into its own issue.

When a file is added to a directory, it will be given a URL like this (assuming native URL use): ipfs://{directory multihash}/{actual filename from client_files}. I would like this to be exposed in the hydrus interface in the following ways:

1. Files can be in multiple ipfs directories, so all of the following requirements should work when a file is in multiple ipfs directories.

2. The in-directory URL(s) for the file should show up as known URL(s).

3. The directory/directories in which the file appears should also show up as known URL(s), kind of like the difference between gallery/post URLs and file URLs for traditional web content.

4. The URL(s) should show up in the media viewer as a clickable/copyable link (same was as I requested in #1312.)

5. The URL(s) should be available in the right click "share" menu, like the multihash for individual files that are pinned are.

   1. This should be available in a sub-menu called something like "ipfs directory URL(s)" where you can select from the ipfs directories that the file is located in. The text displayed for the tree items should be the description as shown in the table in services -> review services -> remote -> ipfs.
   2. There should be an option to either copy the whole directory's URL, or just the file's.

6. (optional) Same as with #1312, if you want to replace the ipfs:// with the "clipboard multihash url prefix" setting in the ipfs service, that would be fine.

   I strongly believe that the known URLs should only use native URL format (since it is universal and will not care about whether a particular gateway is available at some time in the future), but when it comes to actually sharing the URL, I think it is fine to use the "clipboard multihash url prefix." Whether the additional complexity of adding that logic is worth it is up to you.

7. If a file is also pinned in ipfs as an individual file, it should not prevent any of the above from working. That should be presented as its own, separate thing.