Lock rules make incorrect assumptions about default lock directory

[Alizter]

When a user declares their own lock directory in their workspace file:

(lock_dir
 (path custom.lock)
 (repositories mock))

We run into issues when building like:

  $ dune build
  Error: No rule found for default/.lock/dune.lock (context _private)
  [1]

Reproduction case and potential fix in #12712.

[Leonidas-from-XIV]

To explain the issue at hand: we currently always assume there is a dune.lock, even if a user has not declared on in the dune-workspace, it is implied (thus the copy rule fails, as it assumes a dune.lock which does not exist).

In general we should spec out what the behavior of default lock dirs should be:

1. Defining lock dirs in dune-workspace means that these lock dirs are in addition to the default lock dirs (so dune.lock and possibly the dev-tool lock dirs).
2. Defining one or more lock dirs in dune-workspace replaces the defaults dune.lock. This seems to match better with what we do in other cases where redefining something replaces the "standard" definition, but creates issues when users redefine just dev-tool lock dirs, as these would disable dune.lock which is not something users would expect.