Navigation of sibling detail tables is wrong

In transactions that have multiple detail tables, `m.find` behaves incorrectly when iterating their start segments. While the problem was identified in tables starting with the same segment ID, it likely affects sibling detail tables with different segment IDs too.

For example, in a 277 Health Care Information Status Notification transaction, there are four detail tables beginning with `HL` segments discriminated by `HL*03`, which may be `19`, `20`, `21` or `22`. These tables may occur in a parse tree in any order, and `m.find(:HL)` should find the *nearest* one, regardless of its `HL*03` value.

Instead, iteratively traversing these segments using `m.find(:HL)` shows
* The zipper is moved forward to the next `HL*..*..*20`, skipping any other `HL` segments, until no more `HL*..*..*20` occur in the parse tree.
* Then the zipper moves forward to the next `HL*..*..*21`, skipping any other `HL` segments, until no more `HL*..*..*21` occur.
* Next the zipper moves forward to the next `HL*..*..*19` segment, skipping any other `HL` segments until no more `HL*..*..*19` segments occur.
* Finally the zipper moves forward to `HL*..*..*22` segments, skipping any other `HL` segments.

This results in `m.find(:HL)` quietly skipping over several `HL` segments that should have been matched. The problem is that the grammar for detail tables cannot restrict the order in which they occur, unlike every other structure in an X12 grammar, but the Navigation methods assume tables occur in the order in which they are defined.