Impossible to set `configured_value_or`s in a dslx_library to any non-default value.

**Describe the bug**
DSLX has a system where you can use `configured_value_or("ident", default_value)` to create build-time set constants similar to rusts `cfg!` or -D macros in C/C++. These values are set using either the `configured_values` option on build targets that create verilog/xls-ir or with the `--configured_values` flag on ir_convert.

With the way that these values are propagated right now however only flags in files directly in the `srcs` build attribute of the ir/verilog target, or in the list of the cmdline have their value set. All other uses of `configured_value_or` in imported files have their default value, even if the same value is used in the 'top' files.

This behavior is very surprising and is done entirely silently.

**To Reproduce**

library.x

```rust
pub fn foo() -> u32 {
configured_value_or("foo", u32:0)
}
```

main.x

```rust
import library;

fn main() -> (u32, u32) {
(library::foo(), configured_value_or("foo", u32:0))
}
```

BUILD

```starlark
dslx_library(
name = "lib",
srcs = ["library.x"]
)

xls_dslx_opt_ir(
name = "foo_is_42",
srcs = ["main.x"],
dslx_top = "main",
deps = [":lib"],
configured_values = {"foo": "u32:42"},
)

xls_dslx_opt_ir(
name = "foo_is_0",
srcs = ["main.x"],
dslx_top = "main",
deps = [":lib"],
)
```

Looking at the IR

foo_is_42 returns `(0, 42)`

foo_is_0 returns (0, 0)

**Expected behavior**

either:

1) foo_is_42 returns `(42, 42)`

or

2) have a way to set configured_values on the dslx_library too so you can do

BUILD

```starlark
dslx_library(
name = "lib",
srcs = ["library.x"]
)

dslx_library(
name = "lib_is_42",
srcs = ["library.x"],
configured_values = {"foo", "u32:42"},

xls_dslx_opt_ir(
name = "foo_is_42",
srcs = ["main.x"],
dslx_top = "main",
deps = [":lib_is_42"],
configured_values = {"foo": "u32:42"},
)

xls_dslx_opt_ir(
name = "foo_is_0",
srcs = ["main.x"],
dslx_top = "main",
deps = [":lib"],
)

```

https://github.com/google/xls/pull/4985 is an implementation of (1) though there were some objections that having the config values be globally scoped like that is undesirable.