Add extra fields, default values and documentation from man os-release and other OSs

[JOT85]

The basis of this PR is https://www.freedesktop.org/software/systemd/man/os-release.html

I've added fields specified in that man page which weren't in the OsRelease structure before. These fields appear in other operating systems such as Arch, Fedora and derivatives. These are:

• ANSI_COLOR (this is the main thing I found missing!)
• CPE_NAME
• DOCUMENTATION_URL
• BUILD_ID
• VARIANT
• VARIANT_ID
• LOGO

Default values for name, pretty_name and id are now also provided as specified by the man page.

OsRelease::new falls back to /usr/lib/os-release.

Also added tests with os-release files from multiple distros with added weird formatting.

Thanks!

[mmstick]

Should optional keys be Option<String> instead of String?

[mmstick]

I think it'd be better if optional fields are left in the extras hashmap, and accessible through methods.

[JOT85]

I think it'd be better if optional fields are left in the extras hashmap, and accessible through methods.

Almost all of the fields are optional though. In fact, only 3 aren't.

I think all fields in the spec should be present in the struct with additional (unofficial) fields in the hash-map.

I considered making optional fields Option<String> however the API before left optional fields as blank strings if they were not provided so I assumed that was a choice made and stuck to that API.

[JOT85]

Should optional keys be Option instead of String?

I considered making optional fields Option however the API before left optional fields as blank strings if they were not provided so I assumed that was a choice made and stuck to that API.

Just to be clear, I think having fields as Option<String> is a perfectly sensible API and a change to that API is not a bad thing. I also don't mind the fields being blank if no value is specified as that doesn't loose much important information. That was how the original API worked and so I didn't change it. What are your thoughts?

[cgwalters]

(I know this is an ancient PR, but we were considering adding a new use of this crate in a project and I went to look at it and noticed the last commit was 6 years ago, which...isn't wrong since obviously things are stable, but on the other hand I'd like to just know things I depend on are maintained)

Anyways: I think this can just be ..Default::default() right?

[mmstick]

Haven't seen any use case that required updating it. There is already a hash map storing extra fields.