fix: incorrect segment order

[ankushKun]

Added a new OutputStashThenWork state to the DashIterator in stroke.rs to handle correct output order of stashed path segments. For open paths, the stash is output first and then it continues like usual, for closed paths the logic remains same.

edit: fixes #528

[jneem]

Sorry it's taken so long to respond. I don't think a single-segment approach can solve this: this PR makes the decision about whether to output the first dash segment when it reaches the end of the first path segment. But at that point we don't yet know whether the first path segment is part of a closed path or not. For example, consider this test case:

    #[test]
    fn dash_sequence() {
        let shape = crate::Rect::from_points((0.0, 0.0), (4.0, 4.0));
        let dashes = [5., 1.];
        let expansion = [
            PathEl::MoveTo((4.0, 2.0).into()),
            PathEl::LineTo((4.0, 4.0).into()),
            PathEl::LineTo((1.0, 4.0).into()),
            PathEl::MoveTo((0.0, 4.0).into()),
            PathEl::LineTo((0.0, 0.0).into()),
            PathEl::LineTo((4.0, 0.0).into()),
            PathEl::LineTo((4.0, 1.0).into()),
        ];
        let iter = dash(shape.path_elements(0.), 0., &dashes);
        assert_eq!(iter.collect::<Vec<PathEl>>(), expansion);
    }

The current PR will break this test, because it will issue the path (0, 0) -- (4, 0) -- (4, 1) first instead of joining it with the final dash.

I wonder if a possible solution is to put the burden on the caller: we allow the caller to specify that they want the dashes reported eagerly, without a stash.

[RobertBrewitz]

@ankushKun are you actively thinking about this? Otherwise I might give an alternate solution a go.

[ankushKun]

@RobertBrewitz Give it a go! I havent had the chance to look at this further :)