cli: add ability to set project root

[KyrylR]

When files are not on the project_root/simf or project_root/simf or any other source dir but deeper, like project_root/simf/math/module/*add*.simf and in *.simf we specify the crate keyword it would resolve as a project_root project_root/simf/math/module but it should resolve as project_root/simf for the correct LSP analysis

This PR introduces a way to provide a specific project root to help address the issue

[stringhandler]

ConceptACK, but I think you should allow the main entry path to exist outside of the project root.

[stringhandler]

Suggested change

	.value_name("PATH")
	.value_name("PROJECT_ROOT")

[stringhandler]

If this fails anyway, what is the purpose of allowing you to specify it? This feels like the behaviour is the same before this PR

[KyrylR]

I think you should allow the main entry path to exist outside of the project root.

In which case we should allow it?

I do not really understand what do you mean

[stringhandler]

Maybe I am misunderstanding what you want to achieve with this PR. Could you add some example file layouts before and after the PR?

[KyrylR]

This fixes a bug related to the crate keyword, @LesterEvSe probably can explain it better

[LesterEvSe]

Currently we have this structure in simplicityhl-std/simf #3eafe6b.

The problem is that we can't create a tests directory (or anything similar), because the crate keyword resolves relative to the file that is being compiled, not relative to the project root.

Example:

simf/
  lib/
    asserts.simf
  tests/
    asserts_test.simf

We want use crate::lib::asserts::{...} to work inside asserts_test.simf, but right now this is impossible: crate::lib::asserts resolves to simf/tests/lib/asserts instead of simf/lib/asserts. This PR adds an explicit project root so we can have a better project layout than the current one.

On the starts_with check, I'd keep it. If the entry file lives outside the declared root, crate::-relative resolution stops being well-defined: no crate:: path can refer to the entry itself, and any module in the tree that tries to import from it will silently miss.

[apoelstra]

If this fails anyway, what is the purpose of allowing you to specify it? This feels like the behaviour is the same before this PR

Before this PR, crate:: always refers to the directory where main is defined. (What this PR calls the main_path.)

After this PR, you can specify a --project-root which tells the compiler where crate:: should point to. And then the main_path continues to be "wherever main is defined", and is only used to check that the main function is defined somewhere within the project root.

Eventually, presumably, we will have a cargo-like tool (maybe smplx) around the rustc-like simc compiler. This tool will locate its top-level manifest file, Smplx.toml or whatever, and set --project-root to the directory where that file lives. And all source files should live in the tree under that.

If you remove this check, it will let people do confusing constructions that may limit our ability in the future to define Cargo-like projects. I'd prefer to keep it.

[stringhandler]

Ok. My main concern was that this was adding a check that was already done, but I see it allows you to specify a root further up the path than was previously allowed.

[LesterEvSe]

ACK d21f237; tested locally with just check and just check_fuzz