allow passing a path to activate

[Roger-luo]

I think it would be much more convenient if one can pass a path instead of an available package name to create the test environment since path is a more straightforward concept that everyone understands, e.g in a hierarchical project like https://github.com/QuantumBFS/Yao.jl/ we have a lot of component packages live in lib directory, and packages in lib do not necessarily to be listed as a dependency in the Project.toml of upper-level packages, which as a result using name will say xxx isn't installed. But I think it's reasonable to activate a random package locally from a shared environment that has TestEnv installed.

[oxinabox]

I've never fully worked out how exactly it activate works. But I agree, supporting a path would be good.

[ederag]

Here is another motivation to support paths. The recommended way to share a project between Pluto notebooks is

Pkg.activate(Base.current_project())

So it seems natural to replace that call with

begin
	using TestEnv
	base_project = Base.current_project()
	Pkg.activate(base_project); # until Pluto knows that TestEnv.activate should disable Pluto pkg system
	TestEnv.activate(base_project)
end

which currently fails with

TestEnv.TestEnvError("/path/to/package/Project.toml not installed 👻")

    ctx_and_pkgspec(::String)@common.jl:24
    activate(::String)@activate_set.jl:10
    top-level scope@[Local: 5](http://localhost:1234/edit?id=fffa3cba-43f3-11ee-1d2b-db91fbb12088#)

removing the base_project argument seems to work, so as a workaround:

begin
	using TestEnv
	base_project = Base.current_project()
	Pkg.activate(base_project); # until Pluto knows that TestEnv.activate should disable Pluto pkg system
	TestEnv.activate()
end

The issue was that Pkg.PackageSpec is not as permissive as Pkg.activate.
If passed a string as first argument, it has to be the name, not the path.

TestEnv.jl/src/julia-1.9/common.jl

Line 22 in 0b9a63e

pkgspec = deepcopy(PackageSpec(pkg))

In other words, Pkg.PackageSpec blindly put the path into the name field.

[ederag]

Food for thoughts after a shallow analysis (feeling out of my league here),
as an alternative to #39 (which would not allow to use the same Pkg syntax with TestEnv, IIUC ?).

After a look into Pkg.activate code, instead of trying to handle all these possibilities directly in TestEnv,
I'd lean to do it in two passes:

1. Pkg.activate(arg...; kwargs...), minus those specific to TestEnv of course.
2. Analyze this activated project and clone it to tmp, activate this clone, flesh it out with test deps,
   and only then instantiate.

pro: uses the regular activate mechanisms to locate the package (so that part should work with any julia version).
con: two activate instead of one (but it's super fast anyway, and there would be only one instantiate).