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

[allight]

Describe the bug
DSLX has a system where you can use configured_value_or<ty>("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

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

main.x

import library;

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

BUILD

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

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"],
)

#4985 is an implementation of (1) though there were some objections that having the config values be globally scoped like that is undesirable.

[allight]

@cdleary @proppy FYI

[allight]

As far as implementing the 'library-with-config-values' things (which is basically the same as how rust's cfg things work where they are limited to specific crates) I think we could do something like make the --configured_values ir_convert flag have a form of

name@the.full.import.path:ty:value

Since import_data already needs to keep track of the import paths anyway this should be simple enough to implement and the starlark to build up this command line is fairly straightforward.