[SV] Generic SVAttributes

Nobody has claimed this yet.

Currently SVAttributes are intentionally limited to sv.reg, sv.wire(https://github.com/llvm/circt/commit/761b6107e78f8ef89576754731ff5367a1b9060f) and sv.assign(https://github.com/llvm/circt/commit/3a13fbf0530d66fc1048a7b5ec901725e951241d), e.g:

```mlir
%bar = sv.reg svattrs [#sv.attribute<"foo">]
sv.assign %bar, 0 svattrs [#sv.attribute<"baz">]
==>
(* foo *)
wire bar;
(* baz *)
bar = 0;
```

However SV spec says SVAttributes can be attached to everywhere including module/port definitions, statements and expressions (even operators). Actually I have use cases to add vendor specific pragmas to expressions so I want to make SVAttributes more generic. To do this, it would be also necessary to stop inherenting sv.attribute in each op definition. Implementation wise, we can pick and extend the commit(512ae544fbc1a14f) in the original PR.

However there are quite a few problems to extend it to expressions.

1. Transformation must respect sv attributes
SVAttributes might not be semantically discardable(?) so we should change transformations (canonicalizers, HWCleanUp, ..). For example, propagating attributes (e.g. `add(a, add(b, c)){sv.attributes="foo"} => add(a, b, c){sv.attributes="foo"}`) is in general illegal. However it is hard to prevent discarding attributes attached to dead sub operations (e.g. `add(a, add(b, c){sv.attributes="foo"}) => add(a, b, c)`).
2. Positions where SV attributes are emitted
SV Spec doesn't define where these attributes must be emitted. Hence, expected positions of vendor specific pragams are very random. For example, how to specify the position of emitted attributes for `mux(a, b, c):{sv.attribute="bar"}`? e.g)

```
a (* bar *) ? b : c
a ? (* bar *) b : c
a ? b (* bar *) : c
a ? b :(* bar *) c
a ? b : c (* bar *)
```

Start by reviewing the existing SVAttributes support on sv.reg, sv.wire, and sv.assign, then inspect the referenced original PR commit 512ae544fbc1a14f. Study how canonicalizers and HWCleanUp handle attributes, and define both transformation-preservation rules and deterministic emission positions for expression attributes before implementing broader support.

Written by the indexing model from the issue text.