fix: switching to custom lock dir

[Alizter]

Reproduction and fix for #12717.

This test demonstrates two issues.

1. We are making some assumptions about which custom lock directories we have in the workspace. This means that a rule wasn't being loaded or was being expected to exist.
2. When combining the context stanza we get some internal errors. Seems to be fixed by feat(pkg): autolocking #12653.

[Leonidas-from-XIV]

The issue was originally brought up by @mefyl. We apparently never check a case where there just is no dune.lock at all (we check lock dirs in addition to dune.lock but never lock dirs that are named completely differently).

Very nice repro, should be easy to fix. I think the code that determines the lock dir always unconditionally adds dune.lock to the list, but shouldn't.

[Alizter]

@Leonidas-from-XIV I want to explore a fix for this before undrafting. If I manage to fix it I will include it in this PR.

[Leonidas-from-XIV]

It's probably in Pkg_common.lock_dirs_of_workspace where the default_path always gets unconditionally added to the list.

[Leonidas-from-XIV]

Thanks, that is a very fast fix with a good repro case.

[Leonidas-from-XIV]

But what if default_source_path is not in workspace.lock_dirs?

It might be correct; my question is more a behavioral: if the workspace specifies lock dirs, do they exist in addition to the default lock dir or replacing the default lock dir? Personally looking from a user perspective I would assume the latter, but I think it is worth being aware of the choice.