[Tests] Improve embit_utils test coverage

[kdmukai]

Now that #342 has been merged, this should be a pretty straightforward PR.

Current coverage report:

Name                                Stmts   Miss Branch BrPart  Cover
---------------------------------------------------------------------
seedsigner/helpers/embit_utils.py      59     48     40      0    11%
---------------------------------------------------------------------

I recommend writing tests into a new tests/test_embit_utils.py file.

[jdlcdl]

I'd played with this https://gist.github.com/jdlcdl/79392ec1417863c49498815edc7e01bd a while back, so I'll look to continuing towards more coverage.

[jdlcdl]

I'd played with this https://gist.github.com/jdlcdl/79392ec1417863c49498815edc7e01bd a while back, so I'll look to continuing towards more coverage.

simply adding that file to a new branch and running coverage again brings the report to:

Name                                    Stmts   Miss Branch BrPart  Cover
-------------------------------------------------------------------------
src/seedsigner/helpers/embit_utils.py      59     27     40      3    52%
-------------------------------------------------------------------------

...but I have no intention of leaving it like this. This was originally my attempt at exhaustive coverage of a single function. Seeing all that has evolved in your latest testing sprint, I'll convert my style from test functions to test classes and methods and do my best to adopt similar style to remain consistent with the rest of the tests.

To state my intentions on unit-testing... because this particular example is crazy-monotonous and very-boring to maintain, they are:

• to serve as provably correct documentation, for newbs and especially for myself, far into the future,
• to catch api changes (like defaults) in dependencies, before a user finds them in production,
• to get closer to test-driven-development where not a single line of code is written before its unit-test that proves it... but I'm still not convinced this is realistic... just that it's something to shoot for.

In a ideal/perfect unit-tested project... I'd like to believe that an entire codebase could be deleted, and then unit-test files could be divied-out to many different devs and they'd all recreate (or port to another language) the same working codebase in record time.