Add CSS calc

[kokoISnoTarget]

Objective

Fixes: #225

Context

#232 (comment)
https://drafts.csswg.org/css-values/#funcdef-calc

Feedback wanted

Todo

• Change RELEASES.md
• Testing
  • Finish Parser for tests
  • Add tests
  • Test on other systems because of fun pointer stuff:
    • 32bit systems
    • Little and Big-endian systems
    • Non x86 platforms (Arm and whatever)
    • Windows and macOS
  • Miri
    • Look into Strict Provenance / sptr
• Add basic remaining CSS math functions
• Documentation (not the best)
• Performance
  • Don't be 15% slower
• Clean things up
• Impl Serde

[nicoburns]

This looks broadly good to me. I wouldn't bother with a no_std implementation (alloc should be trivial I think). What I would ideally like is for this to be feature-flagged behind a calc feature. Possibly the best way to deal with feature flagging all the .clone()s is to define a new method on Dimension, etc which calls .clone() if the feature flag is enabled and consumes and returns self otherwise. That way the conditional compilation is largely restricted to one place.

However we have a bit of a problem, which is that I am seeing benchmark regressions (run cargo xbench from the root or cargo bench from the benchmarks directory) averaging around +50%. Which is rather a large overhead! And this is on benchmarks without any actual Calc values too. There are two obvious culprits for this:

1. The increase in size of the style types
2. Calls to .clone() not being able to be as easily optimised as memcopy's.

As a quick test I did a find/replace on Taffy's main branch, replacing all f32's with f64s, and this seemed to result in roughly a 20% performance hit. This suggests to me that it might be a bit of both.

My suggestions for resolving this would be either:

1. The combination of:
   a. Using a "tagged pointer" representation (a union) to squash a Dimension down to 64 bits
   b. Adding a DimensionRef type or similar that borrows Dimension to cut down on clones where possible. Methods like resolve_or_zero also ought to possible to make to work without cloning.
   c. As Taffy never holds persistent copies of style types, we could also consider playing fast-and-loose with the borrow checking rules and storing a raw pointer (which could be Copy!)
2. Creating a new global (per-TaffyTree instance) Vec/Slotmap of Calcs. And expecting users of Taffy to register their Calc values there before using the index/id in Dimension (which could potentially be made 32 bits if we did this). Resolving of Calcs would then be done via the LayoutPartialTree trait or similar.

[nicoburns]

@kokoISnoTarget I've been reading some of your commits, and regarding the "union", I suspect you may actually want a newtype around a u32 (or u64 if you need 64 bits). You can then use type casts and bit manipulation operators to access the tag and the value(s).

[kokoISnoTarget]

@nicoburns I'm not quite sure what the problem of my current approach is, but I appreciate the feedback.