Partially for #17; as discussed in #44.

id: link IDs are UUIDs and do not specify filenames, so in order to resolve such links to sections in other files, we will need to somehow identify which file contains the ID.

We can get away with not doing a full org_parser parse of every potential target file by doing something much simpler:

stream file content linewise and just extract the IDs e.g. with /:ID:\s+[0-9A-Z-]+/. On iOS in particular this could mean forcing downloads of files that aren't available locally, but if the majority use case for Org Roam is lots of small files then it could be OK.

This would probably happen in the native layer, with the resulting file identifier being returned to the Dart layer.

As a first attempt I may do this on-demand (no indexing mechanism) and see how it goes. If it's unbearably slow to resolve a link (quite possible for e.g. large Org Roam databases like https://github.com/jethrokuan/braindump/tree/master/org) then an indexing mechanism will be needed.

The index complicates things significantly:

• How do we manage the task in the UI?
  • It will presumably be long-running, so the user needs to know the progress
  • We probably don't want to allow multiple indexing tasks to run concurrently, so some restrictions are needed
• How do we ensure the index is up to date?
  • Can we run it on every file open? How expensive is it to run?
• What should be in it? For each file:
  • Persistable file ID
  • File modification date (for detecting when an update is needed)
  • List of IDs found