Optionally extract all the types in the specification(s)

[tins2831]

There exist many ksy file specifications that have a mess of nested types. It gets ugly real fast:

meta:
  id: food
types:
  potato:
    types:
      bun:
        types:
          steak:
            types:
              chicken:
                enums:
                  cook_method:
                    1: fried
                    2: roasted
                types:
                  cereal:
                    seq:
                      - id: flakes
                        type: u1
                        enum: cook_method
  rice:
    types:
      corn:
        seq:
          - id: kernel
            type: u1
  cabbage:
    seq:
      - id: leaf
        type: u1

from kaitai_local import food

...
if mycereal.flakes.value == food.potato.bun.steak.chicken.cook_method.fried.value:
    # annoyed

I'm positive anyone would be annoyed by that. Users should be allowed to toggle a flag at the command-line interface to tell ksy-dl to extract all the types into a hierarchical structure of files:

└── kaitai_local
    └── food
        ├── cabbage
        │   └── cabbage.ksy
        ├── food.ksy
        ├── potato
        │   └── bun
        │       └── steak
        │           └── chicken
        │               ├── cereal
        │               │   └── cereal.ksy
        │               └── chicken.ksy
        └── rice
            └── corn
                └── corn.ksy

Not only does this make a specification more easier to sift through and use in code, it also becomes modular now:

from kaitai_local.food import food
from kaitai_local.food.potato.bun.steak.chicken.cereal import cereal
from kaitai_local.food.potato.bun.steak.chicken import chicken
from kaitai_local.food.rice.corn import corn
# from kaitai_local.food.cabbage import cabbage <- can omit this now instead of importing it

...
if mycereal.flakes.value == chicken.cook_method.roasted.value:
    # not annoyed

For this to work though, I'd have to:

• Adjust the imports for each type
• Correct the references to subtypes
• (possibly more)

[tins2831]

The same should apply to the dependencies of the initial specification and to enums.