WIP: Stroke dash-array implementation.

Addresses #136 (closed).

Current status is the dash-array parser seems functional. I am not sure about the overall API, when it should return errors and the DashState::Array type.

My thinking is something like stroke-array -> match enum -> action. Although with the current way the Enum is structured it would mean that a call to parse_list_length potentially could return a State::Array(Result<T>) which is like having to take off 2 layers in order to get to the Vec with the values.

Another thing I am not sure is the the part of the spec that references "the sum of the values".

If the sum of the values is zero, then the stroke is rendered as if a value of none were specified.

I assume the value in question is the RsvgLength.length. https://gitlab.gnome.org/alatiera/librsvg/blob/ba82cf82c755617a9868cc0d01429c637dd2f5ad/rust/src/length.rs#L334

About the tests, I scraped the examples from the github repo as you said. Didn't find any mention though of values like "syntax error" and "10 syntax error". And something like that would be kinda difficult to detect without having to regex the string since the dash-array can be whitespace separated. Also the "good" test results are how I interpret the spec and not sure if they are even valid.

Also the spec does not seem to mention what happens on inputs like " \t \n, none " or " \n , " etc. Currently those would pass to the parse_dash_array and Error on something.

Overall it should be on the same performance as the C implementation. I can think of ways to optimize it a bit more like counting the sum along the way we parse RsvgLength and saving an iteration Or findings a better way to repeat the dashes Vec if it's not even.

I am kinda flying blind regarding how to wire it up to the library so I need some guidance there.