Grid/refactor coordinate handling

[nicoburns]

Objective

The handling of grid line coordinates was previously incorrect in a few corner cases (such as specifying -1 span 3). This PR fixes those bugs. It also introduces 2 newtypes GridLine(NonZeroI16) and OriginZeroLine(i16) to represent the coordinate systems

Feedback wanted

What is the best way to expose grid lines to users.

The publicly exposed GridPlacement type is now an alias for GenericGridPlacement<GridLine> (so users who are using the raw types rather than the style helpers must pass a GridLine for the Line variant.

Currently:

• GridLine is a wrapper around NonZeroI16 (zero is invalid)
• For ergonomic reasons line() style helper accepts i16, but returns GridPlacement::Auto if zero is passed.

I'm thinking it might be better if:

• GridLine is a wrapper around i16
• Documentation is added to line() to indicate that zero is invalid (and point to MDN docs on grid lines)
• line() returns GridPlacement::Line(GridLine(0)) if zero is passed.
• GridPlacement::Line(GridLine(0)) gets converted to GridPlacement::Auto internally.

The reason I'm thinking this is that I reckon we'll probably want some kind of debug tooling to introspect styles at some point, and for that we'll need to represent exactly what the user specified (and then indicate it's invalid).

Other alternatives:

• Make the user manually create a NonZeroI16 (but this is incredibly verbose)
• Make line() panic if passed zero (but I think we ought to avoid panics wherever possible).

[alice-i-cecile]

I agree with your assessment of the options. Panicking is bad, and NonZero is a giant pain for anyone writing this out by hand (or serializing it).

[nicoburns]

I agree with your assessment of the options.

Excellent. This has now been implemented :)

[Weibye]

This improves "correct" usage, so I really like these changes.

[alice-i-cecile]

This diff is an indication that we should be using Deref / DerefMut impls on these newtypes IMO.

[nicoburns]

I'm a bit wary of implementing Deref/DerefMut for the coordinate newtypes as a large part of the purpose of the types is to make sure that they are not used in the wrong context and I feel like this would weaken that protection. I've taken an alternative approach of:

• Adding methods to OriginZeroLine. They still use .0 internally, but these .0's are now constrained to the impls for that type (i.e they're all self.0).
• Just using OriginZeroLine directly in more places (avoiding the need to access the inner value entirely).

Does that seem acceptable to you?

I've also uncovered a couple of bugs in the process of this, which all seemed to affect grid items that are auto-placed into negative grid tracks. These now have gentests. At some point I would like to go through and convert all the placement unit tests to gentests, but that's definitely for a separate PR.

[alice-i-cecile]

Generally in favor of this! Two requests:

1. Deref / DerefMut on the newtypes: there's a ton of .0 churn in this diff that makes it unclear.
2. Change log.

[nicoburns]

Release notes updated. User-facing changes in this PR are pretty minor, but there is one small one so I've included it.