Fix precedence of safe-accessor tail

[marcelocantos]

Fixes #552

Change safe-accessor tail to expect an expr instead of the next rule on the precedence stack.

The expression a.b?:c.d used to parse as (a.b?:c).d. This is confusing because it means that .d, which looks like it belongs to c, actually applies to a.b if a has a b attribute. This PR changes it to parse as a.b?:(c.d).

This is actually a bit of a hack. My preference would be to loop back to the current rule. However, wbnf doesn't have a way to refer to the current rule, only the next rule (@) or back to the top (expr). It might be better to add this capability to wbnf. Comments welcome.

Checklist:

• Added related tests
• Made corresponding changes to the documentation

[coveralls]

Pull Request Test Coverage Report for Build 8d2f7b7b1dc05aee43438caf9f604d54f9184dc3-PR-525

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage remained the same at 47.706%

---

Files with Coverage Reduction	New Missed Lines	%
rel/value_set_generic.go	2	74.47%

Totals
Change from base Build cea02743513c00478f8b88caad0546ce96ae2133:	0.0%
Covered Lines:	4533
Relevant Lines:	9502

---

💛 - Coveralls

[orlade-anz]

Can you add a description of what this is actually doing for posterity?

It looks vaguely related to #532 but doesn't fix it.

[orlade-anz]

The description is good but hard to grok; can you also add a test case that would have failed before but should pass now and vice versa?

[marcelocantos]

We really should fix the stack operator in wbnf so that this rule can be self-referential. arr-ai/wbnf#85