Serializing Hsl colors uses a broken legacy syntax

Nobody has claimed this yet.

The following simple test fails:

```rust
// NOTE: Also fails with "hsl(70 8% 15%)" and "hsl(70 8 15)"
let color_str = "hsl(70, 8%, 15%)";
let color: DynamicColor = color_str.parse::>().unwrap().into();

assert_eq!(color.to_string(), color_str);
```

Actual result:

```
assertion `left == right` failed
left: "hsl(70, 8, 15)"
right: "hsl(70, 8%, 15%)"
```

The color is always serialized in the legacy format (comma delimited). But it is broken because the `%` units are required: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/color_value/hsl#syntax

> Note: `hsl()`/`hsla()` can also be written in a legacy form in which all values are separated with commas, for example `hsl(120, 75%, 25%)` or `hsla(120deg, 75%, 25%, 0.8)`. The `none` value is not permitted in the comma-separated legacy syntax, the `deg` on the hue value is optional, and the `%` units are required for the saturation and lightness values.

The `Display` impl for `DynamicColor` with `ColorSpaceTag::Hsl` calls `write_legacy_function()`, which does not add the required `%` units. It looks like using `write_modern_function()` instead would work correctly.

Start at the DynamicColor Display implementation for ColorSpaceTag::Hsl and inspect the calls to write_legacy_function() and write_modern_function(). Run the failing Hsl parsing and formatting example, then verify that serialized saturation and lightness retain the required percent units and that the regression test passes.

Written by the indexing model from the issue text.