Resolve included files during Analyzer preprocessing

[timjroberts]

This PR addresses #15 by accumulating included file paths during preprocessing, and then resolving them as part of the background processing of files. Because included paths are resolved via the Workspaces, the process is entirely recursive.

Tasks

• [x] 1. Consider how best to resolve included paths. We generally only ever want to use absolute paths (especially when used alongside a FileId).
• [ ] 2. Consider how best to report errors (i.e., if a file is physically not present on the underlying file system).
• [ ] 3. Think about what happens when an '#include ...' line get removed.
• [x] 4. Ensure that we resolve included dependencies between changes.

Task Notes

1. While not using on demand inputs directly, I have used the on_demand_inputs page as inspiration, I have extended the Db trait with a new resolve_path(...) function that will return an absolute path by joining a given base, and a target path. This function is then used by the preprocess(...) function when computing a new FileId for an included path. This keeps all referenced paths known to the FileSystem in an absolute form, and (more importantly) unique when stored as FileIds in the Salsa database.

2. The Analyzer will report a missing file through its diagnostics. This is all done separately to the workspace manager which will set an Err(IndexError::NotFound) against the File instance.

3. We don't need to worry about this anymore. If an '#include ...' line is removed then the accumulated dependencies for the associated FileId simply won't include it anymore as part of its new Salsa revision. It will still be present in the Workspace Manager, but that is OK. The Workspace Manager mirrors what is on the 'disk' rather than what the Analyzer currently needs to parse.

4. The Analyzer::preprocessed(...) function will now call a new require_fn for any IncludeDependency for which is_resolved is false. This results in the dependency being loaded in the background and set in the Analyzer.

Future Work

Currently the preprocessor only considers relative paths, and it also doesn't consider the quotation style. As such, an include in the form '#include "core.p4"' will be resolved relative to the file that contains it. This is correct behavior. Future work is required to support the angle bracket quotation style, and in turn, support for multiple paths while resolving. As outlined in the P4_16 specification, the quotation style simply determines the order in which the preprocessor will need to consider these file paths: '"..."' using the relative path ahead of any additional include path list, and '<...>' using the relative path last.

[timjroberts]

The core work for this is now complete. I've identified some future work to support both 'include ...' quotation styles, but landing this PR will close the loop on integrating the Workspace Manager with the Analyzer, and allow other features to progress.