RUST-1933: Support deserializing $uuid extended JSON syntax

[mattChiaravalloti]

This PR updates the extended JSON deserializer to support the $uuid documented here. As noted in the ticket, this behavior now required for the Atlas SQL team. I confirmed locally that this change works for our purposes.

Looking through the code, it seems $uuid is supported in several other places but not for direct serde_json::from_str::<bson::Bson> parsing. I assume this was an accidental omission and not a deliberate choice.

I was unsure exactly where/how to test this. I spent a lot of time looking through the test files but I never quite figured out how/where/if you are testing this specific behavior (parsing extended json strings directly into Bson values), so I added a single, simple unit test to cover this. Let me know if testing should be done elsewhere or another way.

Edit: To be clear, our actual use case is using serde_yaml to parse yaml files that contain extended json values. The files are parsed into structs that have nested Bson fields, which is why this change is relevant and why we can't conveniently use the workaround of parsing into a serde_json::Value and then using TryFrom<serde_json::Value> for Bson. I updated the description to be a bit more lax to make this clear.

[abr-egn]

LGTM!

And yes, this was definitely an accidental omission. As you've noticed the internals of the library are a bit of a mess, we've got time scheduled this quarter to clean that up :)

[mattChiaravalloti]

@abr-egn Thanks for the quick review! 2 questions:

1. Does the lint failure matter for this PR? It's failing on master as well so I figure this is acceptable but lmk!
2. Since I do not have write-access, would you mind merging this for me?

[abr-egn]

1. Does the lint failure matter for this PR? It's failing on master as well so I figure this is acceptable but lmk!

Nope, this failure is unrelated to your PR. Thanks for checking though :)

2. Since I do not have write-access, would you mind merging this for me?

Done!