Remove quick-xml warning by updating dependencies

[John2143]

Hello!

This PR updates the dependencies in Cargo.toml, specifically minidom v0.12 -> v0.15. I encountered the following warning when compiling on version 0.6.0:

$ cargo run
    ...
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 6.54s
warning: the following packages contain code that will be rejected by a future version of Rust: quick-xml v0.17.2

I tried updating the dependencies and it seems that newer version of minidom have dropped quick-xml entirely.

├── minidom v0.12.0
│   └── quick-xml v0.17.2
│       └── memchr v2.7.2

...

├── minidom v0.15.2
│   └── rxml v0.9.1
│       ├── bytes v1.6.0
│       ├── rxml_validation v0.9.1
│       └── smartstring v1.0.1
│           └── static_assertions v1.1.0

[AlecTroemel]

related to this discussion.. #21

[mrguiman]

@AlecTroemel is there anything we can do to help move things forward regarding quick-xml ? I noticed there are 2 PRs open, this one looks like the most painless, do we need to do some testing ?

[rimutaka]

@mrguiman , I think I am still a co-maintainer on this one and can try merging. My understanding is that this crate was superseded by newer, better ways of doing the conversion and should probably be archived. Do you think we should keep it going?

[mrguiman]

@rimutaka that would be up to the maintainers I guess. If there are indeed alternatives and no plan on updating this crate then it wouldn't be to much pain for me to switch, but then yes the repo should probably be archived and the readme updated to point towards said alternatives ?

[AlecTroemel]

@John2143, @mrguiman, and @rimutaka I've had basically zero time to work on this project, but I should have still been more communicative. I apologize.

The internal debate I'm having is, like @rimutaka mentioned, it seems like the rust ecosystem has move on from quick_xml. When we upgrade minidom, this project will no longer be "quick_xml to serde"! I'm guessing the new version of minidom doesn't break anything, and they've changed their internals without effecting the public interface. But the name of this repo would be a misnomer, which I guess is fine for a 20 start project?

@rimutaka if there's a suitable alternative I think archiving would be reasonable.