feat: configuration of project sources

[victor-linroth-sensmetry]

Main new features added by this PR:

• Config options for project sources in sysand.toml (or given config). Allows for portable specification of local and remote sources.
• Command line options --editable, --path, --url-src and --url-kpar for sysand add that automatically updates config file. These also get removed with sysand remove.
• Documentation explaining the above.

In order to simplify implementing the above the core library was build out with the following changes:

• New macro crate with ProjectRead and ProjectMut derive macros for easy enum composition of project structs.
• New CachedProject<Local, Remote> struct for when the Local project is easier to access (e.g. on disk or in memory) vs Remote, but you still want .sources() to give the remote sources.
• Implementation of CombinedResolver simplified using derive(ProjectRead) and CachedProject.
• New ProjectReference<Project> struct. When working with ReadEnvironment the projects need to be clonable, but this might not always be a good idea, e.g. some project hold ownership of temp dirs. ProjectReference is basically and Arc wrapper for a project to be used as a compatibility layer.
• New AnyProject struct combining the different projects supported for source configuration. Should be extended to include Git projects in future.
• LocalSrcProject and LocalKparProject now has optional nominal paths in addition to the regular path. This comes from the choice to have configured source always be relative to the project root but this not always being available everywhere. (Could perhaps be simplified if we added a Global Context).

In addition there where some small changes that came about when experimenting with different solutions:

• MemoryEnv can now be used with a generic project.
• MemoryResolver can be conveniently constructed from iterator/array/Vec.

These ended up not being used here, but they could be useful at some later point so where left in.

[tilowiklundSensmetry]

Is there a particular reason for expanding CombinedResolver with an Override case, as opposed to having a generic OverrideResolver<T> and use StandardResolver = OverrideResolver<CombinedResolver>?

[victor-linroth-sensmetry]

Is there a particular reason for expanding CombinedResolver with an Override case, as opposed to having a generic OverrideResolver<T> and use StandardResolver = OverrideResolver<CombinedResolver>?

No particular reason, just the first thing that came to mind. Do you think that would be a better solution?

[tilowiklundSensmetry]

Is there a particular reason for expanding CombinedResolver with an Override case, as opposed to having a generic OverrideResolver<T> and use StandardResolver = OverrideResolver<CombinedResolver>?

No particular reason, just the first thing that came to mind. Do you think that would be a better solution?

It might be easier to test/mock, and be a bit easier to reuse elsewhere. You can simply have OverrideResolver<Memory/Null> instead of having to create a CombinedResolver<Memory/Null, Memory/Null, Memory/Null, Override, Memory/Null>.

No very strong preference though, so don't bother if it's a lot of work to refactor.

[tilowiklundSensmetry]

Everything looks good to me in principle, would be a good to have a proper code review from @andrius-puksta-sensmetry before merging though.

[victor-linroth-sensmetry]

No very strong preference though, so don't bother if it's a lot of work to refactor.

Well, this was precisely the type of feedback I was looking for, so I'll definitely consider it.

Everything looks good to me in principle, would be a good to have a proper code review from @andrius-puksta-sensmetry before merging though.

It's still a draft so far. I want to add some quality of life command line stuff also.

[victor-linroth-sensmetry]

Currently sysand_core::lock::Source and typed_path::Utf8UnixPath have to be in scope when using the ProjectRead macro. This is certainly less than ideal but it's not obvious to me what the best solution would be.

The problem stem from the fact that reference of types in macros should be absolute but the absolute paths vary depending on if you are inside or outside the crate. E.g. it's ::sysand_core::lock::Source if outside and ::crate::lock::Source if inside. If typed_path::Utf8UnixPath is part of the public API it should probably be reexported by sysand_core and then it's the same problem there.

One could try to add them as associated types to ProjectRead but then you introduce the additional complexilty that it can vary with trait implementations. I'm unsure if thats desirable or necessary.

Another solution would be to refactor the crates so that they are always used outside of the crate where they are exported. Would essentially mean that all the project stuff goes into it's own crate.

[victor-linroth-sensmetry]

Unsure if core/tests/project_no_derive.rs has any value left now that I have it working.

[victor-linroth-sensmetry]

Still left to make sure Windows paths are handled properly (don't think they are at the moment).