cue/load: do not include module ancestor files in the same package by default; make optional

[myitcv]

Currently, per https://cuelang.org/docs/concepts/packages/:

Within a module, all .cue files with the same package name are part of the same package. A package is evaluated within the context of a certain directory. Within this context, only the files belonging to that package in that directory and its ancestor directories within the module are combined. We call that an instance of a package.

As a demonstration of the current behaviour, the following test passes:

exec cue eval ./...
cmp stdout stdout.golden

-- cue.mod/module.cue --
module: "example.com"
-- root.cue --
package example

x: a: 5
-- subdir/subdir.cue --
package example

x: b: 4
-- stdout.golden --
x: {
    a: 5
}
// ---
x: {
    a: 5
    b: 4
}

Feedback from many users has shown this to be a confusing behaviour by default in certain situations:

• I was expecting a Go-like package experience, this is not that.
• I have multiple services defined within a monorepo, each defining its own configuration as part of a config package local to that service. This pattern does not work in that context.
• ... (please reply below with further examples of how/where this is frustrating)

This umbrella issue tracks:

1. Changing the default behaviour of CUE to not include ancestor files in the same package. From experience, this is the most commonly expected default.
2. Proving a configuration option to enable the current default behaviour.

Concretely, the new proposed default would result in the following test passing:

exec cue eval ./...
cmp stdout stdout.golden

-- cue.mod/module.cue --
module: "example.com"
-- root.cue --
package example

x: a: 5
-- subdir/subdir.cue --
package example

x: b: 4
-- stdout.golden --
x: {
    a: 5
}
// ---
x: {
    b: 4
}

Open questions

• Where the configuration option would be set. Likely somewhere within cue.mod/module.cue.
• Whether this would be an all-or-nothing configuration option, or whether there would be a package-level granularity.
• The use of a CUE directive in a cue.mod/module.cue file (or package) to enable this behaviour from a specific release onwards (separate issue to follow).

[myitcv]

As part of this issue we should also consider how/where cue.mod/{usr,gen} fit into the picture.

[myitcv]

Linking to https://github.com/cue-lang/cue/issues/2004, because a change in the default should be gated on a language/toolchain version.