Correctly serialize exports in service rumors

[jamesc]

Solves #5854 by making sure that we always serialize the export configuration as valid TOML.

This PR moves the logic into Cfg::to_exported from the Service::new constructor so we can handle the error more sanely and reuse some of the serialization logic that is already there.

It feels like there might be a more natural way to do this via Serde by constructing some more objects to represent this service config but not sure if it's worth the extra code and abstraction. Would love some input on this.

[thesentinels]

Thanks for the pull request! Here is what will happen next:

1. Your PR will be reviewed by the maintainers
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[baumanj]

This is code in an area I'm not at all familiar with, so it's going to take me some time to give you good feedback. What's the urgency level of this change?

[jamesc]

The bug has been there for a while already and there are workarounds. Doesn't need to be squeezed into this release.

[baumanj]

Apologies for the delay; I'll start digging into this tomorrow

[baumanj]

I've mostly got my head wrapped around this code now (it's kind of a doozy). Hopefully I'll be able to finish this review tomorrow.

[baumanj]

In general, I think we can make this change smaller (see inline comments) and reduce the amount of code we have for serialization by relying more on the external crates.

Additionally, I think we should add a test to components/butterfly/src/rumor/service.rs which explicitly tests the regression. I've confirmed this panics the existing code (with the minor change that Some(map) becomes Some(&map) if we change the cfg parameter to Service::new.

    #[test]
    fn service_cfg_serialization() {
        let package: PackageIdent = "core/foo/1.0.0/20180701125610".parse().unwrap();
        let sg = ServiceGroup::new(None, "foo", "default", None).unwrap();

        // This map contains a scalar value and a table such that the serialization order
        // would trigger a ValueAfterTable error. This test ensures we avoid it.
        // See https://github.com/habitat-sh/habitat/issues/5854
        // See https://github.com/alexcrichton/toml-rs/issues/142
        let mut map = toml::value::Table::default();
        let sub_map = toml::value::Table::default();
        map.insert("foo".into(), 5.into());
        map.insert("a".into(), sub_map.into());

        Service::new("member_id_val", &package, sg, SysInfo::default(), Some(map));
    }