Recursive priorities (or push-priorities, or leafy priorities)

[yannham]

Closes #279. Implement push priority operators as described in RFC001. The general idea is that:

let foo = {
  bar = 1,
  baz = {
    x = "a",
    y = "b",
  }
} in
foo | _push_default

is equivalent to

{
  bar | default = 1,
  baz = {
    x | default = "a",
    y | default = "b",
  }
}

The push priority operators are dynamic and not just syntactic sugar. They operate on arbitrary expressions and are thus not limited to record literals. The syntax _push_default and _push_force is temporary (and ugly on purpose), to proceed with the technical implementation without being blocked by bikeshedding considerations, which can happen after, prior to the next release.

[matthew-healy]

I think this looks good, with the obvious caveat that I'm still very new to the codebase. I left some small comments, but neither needs to block the PR.

[matthew-healy]

Does it ever make sense for a value to be annotated with both _push_force and _push_default? If not, I'm wondering if it could make more sense to model this in a way where it's not possible for both to be true at the same time, e.g.

pub push_prio: Option<PushPriority>

[yannham]

It's indeed fishy semantically, but the thing is that nothing currently prevents the user from doing so:

x | _push_default | _push_force = ...

because annotations are just parsed one by one and combined. In some sense, you can see ExtdAnnot as an AST for meta-annotation, and the source syntax does allow both to be set, just as they were flags. Once it's actually transformed into a term by attach(), it does have to chose an actual push_prio to use.

[dpl0a]

Looks ok to me. I second Matthew's comments though.