[Feature] Hide redundant wrapper types
### The Issue
Let's say I have a wrapper for an array so that I can apply size to the whole array and get a substream:
```
seq:
  - id: some_list1
    type: wrapper_type(count)
    size: size_of_array
types:
  wrapper_type:
    params:
      - id: count
    seq:
      - id: some_list2
        repeat: expr
        repeat-expr: count
```
To access the real data I have to `some_list1.some_list2.data`. But this is redundant... ideally I should be able to just do `some_list1.data`

### Suggested Implementation
```
seq:
  - id: some_list1
    type: wrapper_type(count).some_list2
    size: size_of_array
types:
  wrapper_type:
    params:
      - id: count
    seq:
      - id: some_list2
        repeat: expr
        repeat-expr: count
```
This way whenever I refer to `some_list1` I actually get the `some_list2` object. However with some slight modifications... currently the array `some_list2` doesn't have a substream, so doing `some_list2._io` either doesn't work or gives me the original stream (please correct this so I can edit it in). if it doesn't work then we need `some_list2._io` to refer to `some_list1._io` instead. This should work for whatever properties we create a wrapper type for. In the case of creating a substream then the ability to access that substream shouldn't go away when we hide the wrapper object, instead the child object should inherit those.

### Closely related idea that requires a discussion
Another thought that is closely related, maybe we should add a `hide: false|true` key for elements where we don't really require them when parsing. offsets for example shouldn't really matter when parsing date. This might also help serialization, hidden elements inside `seq:` are a must to write the data but the user shouldn't be able to access them as they are hidden which means the writer must be able to infer them. This way the compiler might be able to detect when hidden data can't be inferred from visible data. This way the compiler throws an error saying it can't generate a serializer. Then we can set a flag to ignore this error in the case that we don't require a serializer. Inversely, if there is visible data that isn't directly set by the user at write time, at the very least a warning might be given. maybe first let it throw an error until serialization becomes officially supported and we are sure it can infer correctly.