cborseq2diag could be nicer if the binary goes on a bit too longer

[mcr]

A more friendly result would be desireable when feeding cborseq2diag with the contents of CBOR encoded flash.
The flash's erase values is 0xff, which is I think, why the CBOR stop has that value.
This means that a program can continue adding to the flash (extending the map, or array easily) without erasing first.

I'm testing this, and with my input of:

obiwan-[RIOT/tests/driver_cfg_page](2.6.6) mcr 10743 %hexdump -C CONFIG.bin
00000000  d9 d9 f8 da 52 49 4f 54  43 42 4f 52 00 19 c6 3b  |....RIOTCBOR...;|
00000010  bf ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*

I get:

55800(1380536148(h'424F52')), 0, 50747, {}, Traceback (most recent call last):
8: from /home/mcr/.rvm/gems/ruby-2.6.6/bin/ruby_executable_hooks:24:in <main>' 7: from /home/mcr/.rvm/gems/ruby-2.6.6/bin/ruby_executable_hooks:24:in eval'
6: from /home/mcr/.rvm/gems/ruby-2.6.6/bin/cborseq2diag.rb:23:in <main>' 5: from /home/mcr/.rvm/gems/ruby-2.6.6/bin/cborseq2diag.rb:23:in load'
4: from /cache/mcr/.rvm/gems/ruby-2.6.6/gems/cbor-diag-0.6.1/bin/cborseq2diag.rb:16:in <top (required)>' 3: from /cache/mcr/.rvm/gems/ruby-2.6.6/gems/cbor-diag-0.6.1/lib/cbor-pure.rb:91:in decode_with_rest'
2: from /cache/mcr/.rvm/gems/ruby-2.6.6/gems/cbor-diag-0.6.1/lib/cbor-pure.rb:315:in decode_item_with_rest' 1: from /cache/mcr/.rvm/gems/ruby-2.6.6/gems/cbor-diag-0.6.1/lib/cbor-pure.rb:273:in decode_item'
/cache/mcr/.rvm/gems/ruby-2.6.6/gems/cbor-diag-0.6.1/lib/cbor-pure.rb:258:in `decode_item_streaming': break stop code outside indefinite length item (RuntimeError)
[3] 21649 exit 1 ./maketest0

And I'd just like something nicer.
Maybe I should write some ruby and catch this error and print my own thing?
I don't think that this is the same as #10, unless I just don't understand that issue.

[cabo]

0.6.3 is even nicer as it produces an error exit code on encountering garbage.

The value for the stop code is entirely accidental: eating ai values from the end caused the 1f component, and the e0 comes from choosing mt7 as that is never indefinite itself and also is the receiver of choice for random stuff.