Consider updating to a new testing framework

[asamuzaK]

From #208 (review)

Also worth noting, but not a blocking issue: the test coverage here is amazing. But I am sad it is not in web platform tests format, which would make it easier to validate that we are matching browser behavior.

I don't know what a good solution to this is since I know having quick to run unit tests in this project is nicer than having to do a full integration test with jsdom.

Some possible ideas:

• Be sure we have jsdom web platform tests for all web platform issues opened by real users. E.g. "webkit-" vs "-webkit-" #70, 'border' setter does not validate new value #124, Values are not properly converted to DOMString #129 (you already added tests), style.setProperty('--x', 0) sets value twice jsdom#3878, Implement CSS unset value jsdom#3833.

• Use AI to port some tests, e.g. CSSStyleDeclaration.test.js and properties.test.js. This is kind of annoying to keep in sync.

• Port the tests to web platform tests format, but write them in a way that they can be run with a small wrapper like https://github.com/jsdom/whatwg-url/blob/414f17a3459b0872baee7a2b77e23953b8a5ccd9/test/web-platform.js#L159-L188 .

[asamuzaK]

The following are my personal opinions and notes.

• Using npm link, you can apply cssstyle to jsdom locally.
• It's convenient that changes made in cssstyle are immediately reflected in jsdom.
• However, switching back and forth between cssstyle and jsdom is quite annoying.
• Even if you narrow the test scope with --fgrep, jsdom launches a local server, which takes a considerable amount of time.
• It would be easier to test cssstyle functions locally rather than transferring them to jsdom each time.
• Currently, cssstyle doesn't provide code coverage, it's better if we did.