Make the project more contributor-friendly

[oliverklee]

To make this project easier to contribute (and reduce the work of the maintainer when someone contributes), I propose we change this project to adhere more to common conventions of open source PHP projects, and also to add more quality tools that help detect problems in contributions, and that generally help raise the code quality.

Particularly, I propose these changes (in no particular order):

• add Composer scripts and dedicated CI jobs for PHP linting in all supported PHP versions (using a build matrix)
• add Composer scripts and dedicated CI jobs for running the unit tests in all supported PHP versions and with the highest and lowest Composer dependencies (using a build matrix)
• add Composer scripts and dedicated CI jobs for style checks with CSS_CodeSniffer and/or PHP-CS-Fixer
• add Composer scripts and dedicated CI jobs for static type checks using PHPStan (which I'd prefer) or Psalm
• install PHPUnit as a Composer dependency or via PHIVE
• flatten the directory structure of the production code by changing the css/src/TBela/CSS/ to src/
• rename the test case (the classes) to have the Test suffix
• properly separate the test classes and the fixture files using a tests/Fixtures/ or tests/fixture/ directory
• add code coverage and a code coverage badge
• add a CONTRIBUTING file and a CODE_OF_CONDUCT
• add composer-normalize to the CI toolchain
• add Dependabot for Composer and GitHub Action updates
• switch the default git branch from master to main #147
• drop the composer.lock from the project (as this is a library, not a stand-alone project)

I would probably be willing to help.

@tbela99 What do you think?

[tbela99]

• I already have a GitHub action running a composer script in place
• I use phpStorm which is an excellent IDE. No need for an additional type checker. I can share the license with contributors
• switch the main branch from master to main. Can you elaborate on the need to do that?
• changing the css/src/TBela/CSS/ to src/. I will do that
• I used to use appveyor to run automated tests until there was a security breach. I use GitHub actions since then.
• I have decided to include the composer.lock for a reason which is to lock dependencies and avoid supply chain attacks.

You are welcome to go ahead with your suggestions

[tbela99]

I would suggest you create an issue for each of your suggestions