Refactoring this into *the* rust nmea parser

It would be nice if rust finally had a go to nmea parser that is used by as many people as possible. Considering NMEA is a kinda easy data format to parse / handle usually this shouldn't be too hard to unify reasonably for everyone either. As of now there are 7 nmea related crates on crates.io.

1. This one which with 4583 downloads seems to be the most popular one as of now
2. https://github.com/nicolas-goudry/nmea-0183 by a member of this working group which has tests for each sentence as its most notable attribute.
3. https://github.com/nsforth/nmea0183 this has no dependencies at all as well as no_std support as its most notable attributes.
4. https://github.com/hargoniX/yanp (mine) which has the combination of support for lots of sentences + no_std support as its most notable attribute
5. https://github.com/49nord/titanic-rs which can only parse GGA sentences, whether it has something special about it that might be interesting for us I don't know
6. https://github.com/frafra/frakegps which emulates a GPS receiver that emits NMEA codes, however as it appears only for GGA code as well but maybe the ideas there could be useful for fuzzing related things.
7. https://github.com/dndx/pitot which as far as I can see from isn't exactly useful for us? Feel free to correct me on this or any of the other statements though.

I believe that the core requirements for our NMEA parser should be that:

- [x] It should be no_std as things that use NMEA directly are often gonna be embedded devices. (see 3. and 4.) #10
- [ ] Should have as many tests as possible (see 2. and fuzzing 6.) #11
- [x] Should have as little requirements as possible, considering the size constraints on embedded devices (see 3.)
- [ ] Should under no circumstances ever panic but always return an error, again in an embedded device there is nobody to look at your panic with their eyes. #12
- [x] ~Should maintain API compatibility with the current crate so it is no hassle to upgrade for already existing users.~ @elpiel : We can break the API following semantic version and in the name of usability and idiomatic APIs
- [x] Shouldn't make use of alloc as for some embedded devices you either don't have or don't want to use an allocator for various reasons. #13 #10
- [ ] Another cool and optional feature could be to expose our library functions and structs via the C FFI so they could be easily integrated as a piece of safe and fast Software into already existing C code bases or other code bases that can call into C. #14

It seems to me like especially the point with no dependencies seems kinda hard to adopt, especially when looking at timestamp data because it might be nice to have a well known data structure the user can use in his program. Parsing *could* be done without dependencies as 3. shows, however I don't think this should be our first target to tackle as it seems like a quite huge effort, would definitely be nice to have in a final version though.