[TASK] Use delegation for DeclarationBlock -> RuleSet

[JakeQZ]

... rather than inheritance.

This will allow DeclarationBlock to instead extend CSSBlockList in order to support
CSS nesting.

This is a slightly-breaking change, since now CSSBlockList::getAllRuleSets() will include the RuleSet property of the DeclarationBlock instead of the DeclarationBlock itself.

Part of #1170.

[coveralls]

coverage: 59.595% (-0.2%) from 59.816%
when pulling e666f5e on task/declarationblock-delegate-ruleset
into b2028eb on main.

[JakeQZ]

Would be good to resolve #1247 before moving on with this.

[JakeQZ]

This is almost ready for review, but some tests need to be added. Before doing so, I'd appreciate a pre-review from you: @sabberworm, @oliverklee.

I'm not keen on the having the various chaining methods in DeclarationBlock, but to avoid breaking changes they are necessary. A trait can be used for testing them in the same way as their counterparts in RuleSet.

For DeclarationBlock to contain nested rules, it needs to extend CSSBlockList. RuleSet cannot be a trait; it needs to be a fully-fledged type for methods like getAllRuleSets().

This is the only realistic way forward I see for now, in an 'Agile' sense, which can deliver what is required now, without wholescale refactoring or breaking changes.

[oliverklee]

I like this approach!

[oliverklee]

Maybe as another spin-off PR (or prepatch), we can introduce the interface and have one class implement it.

[JakeQZ]

If I could somehow reset the branch to the state it was in immediately after the commit "Reorder construction"

git reset -hard {SHA-of-last-commit-before-attempted-rebase}

... undid the failed rebase/merge. I think when I tried merging instead (via GitHub), that moved the 'common ancestor' point, but when I reverted the merge, it was not moved back.

then squashing may be possible, but I'm not sure how to do that.

git reset -soft {SHA-of-first-branch-commit}
git commit --amend

... did the squashing.

In my experience, when I had a PR from which I spun off some pre-PRs, I also sometimes had nasty merge conflicts when rebasing. In those cases, it made things a lot easier if I squashed the existing commits in the PR branch before rebasing.

That helped immensely; thanks. Instead of (presumably) 9 rounds of conflict resolution, including for files with no overall conflict, there was just one round, for the two files that actually had conflicts. (I'm used to Perforce, which does the merge all at once, and also has a visual editor for 3-way merging. Keeping a cool head also helps ;))

Rebase now done !) Thanks <3

[oliverklee]

I'm used to Perforce, which does the merge all at once, and also has a visual editor for 3-way merging.

I use PhpStorm as my IDE, and IIRC it also have a nice 3-way-merge UI. (Disclaimer: I don't use UIs for git stuff and hence can only report what I hear and see from other people.)

[JakeQZ]

I think this is now ready for a final review.

[JakeQZ]

This issues from the last review should all now be resolved.

[oliverklee]

LGTM. ❤️