Unify Argument and Member model-types

Currently the Core IDL / interface model has one **Argument** type and one **Member** type.
Argument is for Method arguments, Members are the items that make up a Struct.

The only difference [in the definition](https://github.com/COVESA/ifex/blob/e02878037c5c51a68c88698f18c77328bb5de5d5/ifex/model/ifex_ast.py#L23) is that Arguments can apply a Range (which would augment or overrides the range specified by the item's datatype, if the datatype specifies a range).

The rationale for range in method Argument is, by the way:

1. It is _appropriate_ that a particular use of a datatype in a particular context (method) can apply its own unique constraints on the given argument
2. It is _convenient_ to not have to define a new unique type to achieve this.

We could use the same rational for Structs and claim that the usage of a "more primitive" type as a member inside a struct, might want to apply its own constraints.

If we redefine the model to state that struct members are of type Argument instead of type Member, then the types are unified into one:

Pros:
- Further unification of concepts. Simplification of model and could facilitate code reuse/consolidation.
Cons:
- It potentially increases complexity of implementation for Structs to be forced to handle Range

It should basically be a backward compatible change too, because the YAML syntax does not change (the names of the parts in an Argument and Member are the same), and we are only _adding_ a new potential item to the struct member, which is also optional.

Footnote:
"Range" concept is due for rework in a future spec release anyway. More generally, it is about "Type constraints" that could be more than just specifying a range.

Start in ifex/model/ifex_ast.py at the Argument and Member definitions and inspect how struct members and method arguments are represented. Check the existing YAML model expectations described in the issue, then determine whether one unified model can preserve the current syntax while allowing the optional Range on struct members. Done means the model and its consumers consistently use the unified type without breaking backward compatibility.

Written by the indexing model from the issue text.