@Proto does not fully work on classes that extend other classes

Hello,

I'm using the `@Proto` annotations on classes I want to marshall in an infinispan cache, as described here :
https://quarkus.io/guides/infinispan-client-reference#annotation-based-serialization

But I cannot find how to make it work on classes that extends other classes.

Here is an example :

```
public class Parent {
public String id;

public Parent() {
this.id = UUID.randomUUID().toString();
}
}

@Proto
public class Person extends Parent {
public String name;

public Person(){
}

public Person(String name) {
super();
this.name = name;

}
}

@ProtoSchema(includeClasses = {Person.class })
interface Schema extends GeneratedSchema {
}
```

But the id field from the Parent class is not included in the result :


I then tried to add the annotation `@Proto` on the Parent class and declare the class in @ProtoSchema :

```
@Proto
public class Parent {
public String id;

public Parent() {
this.id = UUID.randomUUID().toString();
}
}

@Proto
public class Person extends Parent {
public String name;

public Person(){
}

public Person(String name) {
super();
this.name = name;

}
}

@ProtoSchema(includeClasses = {Parent.class, Person.class })
interface Schema extends GeneratedSchema {
}

```

But I then get this error :

> C:\dev\git\quarkus-test\src\main\java\com\test\Person.java:22
> java: org.infinispan.protostream.annotations.ProtoSchemaBuilderException: Duplicate field number definition. Found two field definitions with number 1: in name and in id, while processing com.test.Schema

So is this a bug or a current limitation with inherited classes ?
Do I have to explicitely define a custom proto schema instead on relying on annotations ?

Note: Using Protostream 5.0.5.Final (dependency coming with Quarkus 3.12.2)

Start with the @Proto and @ProtoSchema examples in the issue and reproduce the behavior using Protostream 5.0.5.Final, first including only Person and then including Parent and Person. Check how inherited fields and generated field numbers are handled, including the duplicate-number error. Done means establishing whether inherited fields should be serialized and either correcting that behavior or documenting the required schema approach.

Written by the indexing model from the issue text.