Parsing of vendor-specific extended sentences that are not included in the `SentenceType` fails.

[ekuinox]

Regardless of the sentence type, if it is correct as NMEA0183, one would expect it to be parsed using nmea::parse_nmea_sentence, but parsing fails if it is not included in SentenceType.

I don't have any ideas about what to do with the existing PGRMZ, but would it be possible to add an enumerator like VendorExtension(&str) to the SentenceType to handle it?

[elpiel]

There's definitely a place for improvement here. It makes sense to keep our current validation process - if we don't have a parser for the sentences - return an error, however, we could improve the vendor specific sentences although not sure what you envision for it.

PGRMZ is the only Vendor specific sentences and I think it's a good time to discuss how we should handle them

[ekuinox]

For example, if the talker is P and the following vendor code is ABC and the following buffer is abcdefg*hh, I want NmeaSentence to be

NmeaSentence {
  talker_id: "P",
  message_id: SentenceType::VendorExtension("ABC"),
  data: "abcdefg",
  checksum: hh,
}

I would like to make sure that PGRMZ, which already has an implementation, can also fit into this form once without being treated as special.

[elpiel]

Ok, so my current line of thought is to allow a callback for parsing unknown sentences, which will be great to the user as they will add the vendor-specific sentences instead of us.
A few things to consider:

• Re-export nom
• Re-export common functions for parsing various parts of a sentence, maybe we will start without this as we are not sure which common parsing fns are needed