Include subsegment information when aggregating split statistics

[forestbelton]

Fixes #432

Description

Extend util.Statistics so that it breaks out statistics for segments which include subsegments.

I extended the base Segment type to include a property statistics for querying subsegment statistics, defaulting to the current segment information only. CommonSegGroup overrides this to provide aggregated statistics based on all of its subsegments.

Caveat

This change has the effect that a segment inheriting from CommonSegGroup will not be itself included in the statistics output. An example is given in the test output below.

I'm not sure if this is desired behavior, but I couldn't figure out a way to incorporate both subsegment information and retain the segment name without changing the output into some kind of tree format.

Test output

Using the following segment configuration:

segments:
  - [0x0, header]
  - type: code
    start: 0x800
    vram: 0x8002D000
    subsegments:
      - [0x800, bin]
      - [0x101f8, asm, a]
      - [0x102a8, bin]
      - [0x349a8, asm, b]
      - [0x349c8, bin]
      - [0x34b50, asm, c]
      - [0x34bd0, bin]
  - [0x80000]

Before:

Split 524 KB (100.00%) in defined segments
              header:     2 KB (0.39%) 1 split, 0 cached
                code:   522 KB (99.61%) 1 split, 0 cached
             unknown:      0 B (0.00%) from unknown bin files

After:

Split 2 KB (0.45%) in defined segments
              header:     2 KB (0.39%) 1 split, 0 cached
                 asm:    336 B (0.06%) 3 split, 0 cached
             unknown:   521 KB (99.55%) from unknown bin files

[AngheloAlf]

The old code was checking for bin types too.
I'm not sure if we should keep that check tho, naming the section itself could be considered as it being known, idk.
What do you think @ethteck ?

[ethteck]

yeah I think considering it known if it's named is totally fine, personally

[ethteck]

Thanks for this! Just one q

[ethteck]

Is there a reason for this change?

[forestbelton]

Just a type alias to make the types for the code I introduced more self-documenting — certainly not necessary

[ethteck]

ahh I hadn't understood the full context of it. thank you!

[ethteck]

yeah I think considering it known if it's named is totally fine, personally

[ethteck]

@forestbelton before I merge, could you add an entry to the changelog for this? Under 0.32.1