Tests: fix recording code coverage for Tokenizer tests

[jrfnl]

Description

Tests: new AbstractTokenizerTestCase class

Until now, code coverage was not being recorded for the Tokenizer tests due to the way the tests were set up.

This new AbstractTokenizerTestCase class is intended to fix this.

Background info:

• Code run in a setUpBeforeClass() method does not cause code coverage to be recorded.
• Code run in a setUp() method does cause code coverage to be recorded.

Now, the AbstractMethodUnitTest test case class was originally set up to allow for testing the utility methods in the File class.
To do so in the most efficient way and to allow the tests to be fast, the file containing the code being used in the tests, is only tokenized once in a setUpBeforeClass() method.

Over time, when Tokenizer tests were being introduced, the AbstractMethodUnitTest class also started to be used by these, which was fine as code coverage wasn't being measured or recorded anyway.

However, this last part has been changed recently via PR #144, so now it is time to ensure that the Tokenizer related tests record code coverage too.

This new test case class allows for that by moving the tokenization of the code used in the tests from setUpBeforeClass() to a setUp() method.
As the tokenized file won't change during the test run, this is still only done once, but as that "once" is now in the setUp() method, it should allow for code coverage to be recorded.

Note: while code coverage can now be measured and recorded for Tokenizer related tests, it will still not be very precise as the Tokenizer\PHP class contains "monster methods", which means that the @covers tags in the Tokenizer related tests cannot be set up to target only a small, specific part of that class, as targeted by the test. But that's a problem for another time.

Implement use of the new AbstractTokenizerTestCase class

AttributesTest: add missing @covers tag

Suggested changelog entry

N/A

Related issues/external references

Loosely related to #146

[jrfnl]

Note: yes, the CI builds will be slower due to this change. This is mostly due to the code coverage calculations during the test run being very slow on PHP 5.4. This can't be helped, though the impact should be much less for the 4.0 branch in which the minimum PHP version becomes PHP 7.2.