Idea: Blazor inline component

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

it happens that the required set of attributes in a tag is needed only in one file. In this case, you can:

1. either duplicate these attributes for each case. Accordingly, the disadvantage is duplication.
2. Or put it in a separate component. Then there are features of a separate component, its separate render, and this logic may have to be further processed somehow. and an extra file

I would like this small component not to be processed as a separate Blazor component.

### Describe the solution you'd like

Let's take an example. We have 3 buttons with "hello", "world" classes. And the type of button. First and last button also have some margin left and right classes.

```
Btn1
Btn2
Btn3
```

# First option (QML like)
I want to write something like this

```
@component("MyInput"){

}

Btn1
Btn2
Btn3
```

With some custom attribute application policy, for example, addition or complete redefinition (in this example, the component class will be supplemented with information about margin.

the same convenient function is [available in the QML language](https://www.qt.io/blog/new-qml-language-features-in-qt-5.15).
Syntax:
```
component : BaseType {
// declare properties and bindings here
}
```
Example:
```
component MyBtn : Button {
color: "red"
margin: 4
}
MyBtn { text: "Btn1" }
MyBtn { text: "Btn2" }
MyBtn { text: "Btn3" }
```

# Second option (composition like)

We will write a certain set of attributes and give it a name, and the assembly will try to push them into all the tags where we specify this set of attributes
```
@compose_attributes("MySet"){
class="hello world",
type="button"
}
Btn1
Btn2
Btn3
```
In this case, we have the advantages of composition in that it is possible to deploy several different sets of attributes in one tag

# Important

please note that both methods do not pretend to change the logic of the render. All they do is add a step before compilation to expand this syntactic sugar into what it looks like with manual duplication. And handle errors related to this as if the code was written by hand

(here, of course, the second option is much less advantageous, because it turns out to have a very dynamic nature)

### Additional context

Perhaps it has something in common with these requests.

https://github.com/dotnet/aspnetcore/issues/33361
https://github.com/dotnet/aspnetcore/issues/44867

Perhaps this can be solved at the Render Fragment level, but it is more verbose