Fix interpretation of nested blocks with volume-keep-priority

[bertfrees]

This is one commit from https://github.com/brailleapps/dotify.formatter.impl/pull/97 that I was able to separate from the rest.

See also https://github.com/brailleapps/dotify.formatter.impl/pull/97#issuecomment-490462994.

This changes how the actual volume-keep-priority values between/before/after blocks are computed from the specified values of the blocks. It was not so clear how it worked before, but this is how it works now:

• The computed volume-keep-priority value at the beginning/end of a block but after/before the block's border and/or padding is zero, i.e. we never split there.
• The computed volume-keep-priority value inside a block with no children, i.e. between two text lines of that block, is the value of the closest ancestor block that specifies a volume-keep-priority (or the highest value if there is no such ancestor block).
• The computed volume-keep-priority value between two blocks is the value of the closest ancestor block that specifies a volume-keep-priority (or the highest value if there is no such ancestor block).
• The computed volume-keep-priority value before a block that has no preceding sibling block is the computed value before the closest ancestor block that has a preceding sibling block.
• The computed volume-keep-priority value after a block that has no following sibling block is the computed value after the closest ancestor block that has a preceding sibling block.

This behavior should also be made clear in the OBFL specification.

This change also significantly simplifies the code.

[bertfrees]

@kalaspuffar Does this have any effect on the regression tests?

[kalaspuffar]

Hi @bertfrees

I've reviewed the code. I'm starting the regression tests now.

Best regards Daniel

[kalaspuffar]

Hi @bertfrees

162 changes to the regression tests. Need to analyze it further to see what might be the changes.

best regards Daniel

[kalaspuffar]

Hi @bertfrees and @PaulRambags

I've now run the regression tests for this PR too and the result is identical to earlier results so this change did not change the end result. So it seems safe to merge this one as well when @PaulRambags have reviewed the code.

Best regards Daniel