RFC: target semantics of v2-run: deconflict

`v2-run`'s (documentation)[https://www.haskell.org/cabal/users-guide/nix-local-build.html#cabal-v2-run] says this about the interpretation of target name:

> `cabal v2-run [TARGET [ARGS]]` runs the executable specified by the target, which can be a component, a package or can be left blank, as long as it can uniquely identify an executable within the project. Tests and benchmarks are also treated as executables.

This specifically includes ***a package***, which has the following properties:

1. only defined in case when that package has a single executable -- otherwise it's ambiguous and is rejected
2. one particularly painful conflict is when the multi-executable package's name coincides with the name of one of its executables -- thereby shadowing it
3. only case where it really adds expressivity is when the package name _does not_ coincide with the name of the single executable of the package.

# Judgement

So, one can posit, that the use case in point 3 is vastly more niche than the use case in point 2.

As things currently stand, however, the use case 3 is satisfied, at the cost of making use case 2 more painful.

# Proposal

Undo the current unfair situation and eliminate the possibility of referring to an executable indirectly via its package name -- in `v2-run` only, of course.

Then we never will have to add `exe:` to disambiguate between a package name and its executable. (Of course that says nothing about conflicts between executables and test suites/benchmarks).

Start with the linked v2-run documentation and inspect the current target interpretation for package names and executable names. The change is complete when v2-run no longer resolves an executable indirectly through its package name, avoiding the proposed package/executable conflict without changing other target forms.

Written by the indexing model from the issue text.