Fix handling of standalone .cbor and tagged types

[SebastienGllmt]

Fix #91

Currently this fails with the following error that I don't really understand

error[E0308]: mismatched types
   --> src/lib.rs:654:37
    |
654 |         deser_test(&CborInCbor::new(Foo::new(0, String::new(), vec![]), 9))
    |                     --------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `FooBytes`, found struct `Foo`
    |                     |
    |                     arguments to this function are incorrect
    |
note: associated function defined here
   --> src/lib.rs:63:12
    |
63  |     pub fn new(foo_bytes: FooBytes, uint_bytes: u64) -> Self {
    |            ^^^ -------------------  ---------------
help: try wrapping the expression in `FooBytes`
    |
654 |         deser_test(&CborInCbor::new(FooBytes(Foo::new(0, String::new(), vec![])), 9))
    |                                     +++++++++                                  +

[rooooooooob]

The error it fails with is in one of the unit tests. It's treating the test that's:

foo_bytes = bytes .cbor foo

; since we don't generate code for definitions like the above (should we if no one refers to it?)
cbor_in_cbor = [foo_bytes, uint_bytes: bytes .cbor uint]

in the core unit test group (tests/core/input.cddl / tests/core/tests.rs. there should be one in preserve-encodings too, but this might not be an issue since it's not creating from rust).

Before we considered that anywhere taking in foo_bytes should only care about that it's conceptually a Foo and not how it's encoded, we only took in a Foo in all parameters. I think this is a very worthwhile property to preserve. If that unit test is failing to compile that means we are now forcing it everywhere to be its own FooBytes wrapper type which is less usable. IMO we should only generate the wrapper struct if no one is referring to foo_bytes in the CDDL elsewhere, or have the behavior be a toggle with some comment flag to choose.

[SebastienGllmt]

TODO: somebody needs to go through and check if this PR is still necessary (other than the commit that deletes unused code) given #117 was merged