Remove some method names that assume y pointing down

[nical]

With this PR, the only things in euclid that dictate the direction of the y axis are:

• Rect::inner_rect / outer_rect
• Box2D::inner_box / outer_box

---

This change is 

[nical]

This is an incomplete alternative to #361 and #353.

I don't have good ideas for SideOffsets2D member names that are agnostic to the y axis orientation without being awful, but since I'm unlikely to get consensus on either of #361 and #353, I think that I might propose this one and call it a day.

r? @kvark and/or @Manishearth

[kvark]

Can we have SideOffsets just storing things like x0, x1, y0, y1?

[Manishearth]

r? @pcwalton @nox

I don't use these in my code, but I know servo layout does

[nical]

The second commit renames SideOffsets2D's top/right/bottom/left into y0/x1/y1x0.

Caveat

One would think that it would make more sense for the structure and parameters to be laid out in the order "x0,y0, x1, y1" or "x0, x1, y0 y1", except that doing this means the order of the parameters SideOffsets2D::new:

• doesn't match the CSS syntax anymore,
• becomes wrong in all current uses of the method (and I think that there lies madness).

So far, @kvark, @Manishearth and @SimonSapin have expressed various levels of agreement about doing something like this in principle (ranging from, "OK" to "meh, OK". Personally I am not a huge fan but it's good enough for me and makes euclid agnostic to the orientation of the y-axis which is good.

I think that this can be a controversial change so don't hesitate to cc people who use euclid and side offsets a lot.

[SimonSapin]

How about removing SideOffsets2D::new? Four parameters with the same type are easy to get in the wrong order.

[nical]

How about removing SideOffsets2D::new?

This would be nice except for the extra PhantomData field which would have to be passed every time.

[bors-servo]

☔ The latest upstream changes (presumably #368) made this pull request unmergeable. Please resolve the merge conflicts.