type-level width

**Type of issue**: feature request
**Impact**: API modification
**Phase**: proposal

Currently, Chisel manages the width of Data at value-level. So we write modules like this:
```
class SomeModule extends Module {
val io = IO(new Bundle {
val rx = Input(UInt(8.W))
val tx = Output(UInt(1.W))
})
```

This is fine while we write modules as class, but when I try to write the same thing as a function, a problem arises, because I can't specify the width of `UInt`.
```
def someModule(rx: UInt(8.W)): UInt(1.W) = {
// syntax error!
}
```

So we are forced to write modules as class, but there's too much boilerplate IMO...

With Scala 3 supporting match types, we can implement type-level natural numbers and its operations(+, -, *, max, min, etc...) quite easily, so I think we can provide API like this:
```
def someModule(rx: UInt[W8]): UInt[W1] = {
// valid syntax
}

class SomeModule extends Module {
val io = IO(new Bundle {
val rx = Input(UInt[W8])
val tx = Output(UInt[W1])
})
}
```

With this API we can get a better errors from IDE because a mismatch of width emerges at compile-time.

What do you guys think? Will this change cause other problems? One thing I could imagine is that width-inference of literals won't work? I mean there's no way we could determine the width of a value "b11111" at type-level...

I know this is a big change so I don't think we can implement it soon, but when we move to Scala 3, backward-compatibility breaks anyway, so that time is the good timing to do a big change I think...