[enhancement] Support named parameterics in DSLX procs

### What's hard to do? (limit 100 words)

Currently, DSLX parametric procs allow default values for parameters, but all parametric arguments must be provided in order. To change a later parameter, all preceding parameters must be explicitly specified. This can lead to verbose and error-prone code when only one or a few parametrics need to be customized, and the rest of them can use the provided defaults. Being forced to write all preceding parameters makes code harder to read, especially as the number of parameters grows.

A concrete example of this issue is the [RamModel](https://github.com/google/xls/blob/baa713e54d7cc69f46b729506f37f21a51a2da94/xls/examples/ram.x#L165). When modifying the `INITIALIZED` parameter, it is also necessary to explicitly specify the public parameters `DATA_WIDTH`, `SIZE`, `WORD_PARTITION_SIZE`, and `SIMULTANEOUS_READ_WRITE_BEHAVIOR`. Even if the other values are intended to remain unchanged, their defaults must still be manually duplicated at the point where `RamModel` is spawned:

```rust
spawn ram::RamModel<
DATA_WIDTH, RAM_SIZE, WORD_PARTITION_SIZE,
ram::SimultaneousReadWriteBehavior::READ_BEFORE_WRITE, true>
>(rd_req_r, rd_resp_s, wr_req_r, wr_resp_s);
```

### Current best alternative workaround (limit 100 words)

The workaround is to always provide all parameters in order, using default values explicitly for those you don’t want to change. This leads to long, repetitive calls even if only one parameter needs to differ. Alternatively, users refactor procs to reduce the number of parametrics or rearrange parameters so the most changed ones come first. However, sometimes parameters are equally important.

### Your view of the "best case XLS enhancement" (limit 100 words)

One possible improvement is to support named (keyword) parametertics for spawning procs. This would let users specify only the parameters they want to override by name, like `MyProc()`, while other parameters use their default values. Such a feature could improve code clarity, reduce verbosity, and lower the risk of errors.

The same `RamModel` spawn from the previous example can be simplified to:

```rust
spawn ram::RamModel<
DATA_WIDTH, RAM_SIZE, WORD_PARTITION_SIZE, INITIALIZED=true>
>(rd_req_r, rd_resp_s, wr_req_r, wr_resp_s);
```