Add output_extensions option to PrettyConfig

[juntyr]

This PR adds an extra on-by-default configuration option to PrettyConfig. When output_extensions is set to false, the serialized RON will not include the #![enable(EXTENSION)] attributes.

This would also be related to #281, i.e. for use cases where RON is used e.g. for a configuration file that is both produced and consumed by the same program, extensions could be automatically enabled on deserialization and removed on serialization to remove the overhead.

While programmatically enabling extensions is doable already (just insert the attribute-enabling string before the RON), disabling them is much harder as you would have to parse and match on the attributes' format.

• I've included my change in CHANGELOG.md

[juntyr]

@torkleyy One last PR (for now) that adds a tiny bit of extra functionality. Due to its relation to #281 I'd be very interested if you think this is the correct design for this feature.

[torkleyy]

I was a bit skeptical about this originally, but I think this is the best solution.

However, I think we should provide a safer API to make it less confusing and error prone. I was thinking something like this:

fn ron_options() {
    ron::Options::build().implicit_some().build()
}

let ron = ron_options();

let foo: Foo = ron.from_file("foo.ron")?;
ron.to_file("foo.ron")?; // same options used for deserialization and serialization
ron.to_file_pretty("foo.ron", PrettyConfig::default())?;

We should also make sure to provide such a code snippet as documentation and to explain that one has to use the same options for serialization and deserialization. I think doing all this cleanly might involve some breaking API changes, not sure.

[torkleyy]

I think we should describe the use-case here and what to look out for (enabling the same extensions when deserializing).

[juntyr]

I really like the design you are proposing here. Do you think it would be best to first implement this new API and then after that the functionality to turn off the extension outputting? I might make sense to give a nicer usage example.

[torkleyy]

Yes, I think that would be the best approach @MomoLangenstein 👍

[juntyr]

Yes, I think that would be the best approach @MomoLangenstein 👍

Ok, I'll write that up then (maybe tomorrow)

[juntyr]

This PR will be superseded by #343 and closed once that is merged

[juntyr]

With #343 this has now become obsolete