Create phar build flow

[jaapio]

Phar releases are needed to be able to use prophecy in projects that are dependencies of prophecy.

As described in #30.

Because phpunit includes prophecy right now we cannot include prophecy in the phar right now. So we need to change that when phpunit 10 is released.
For now, the phar can be installed next to the phpunit.phar in tools/phpunit.d

The configuration below shows how

<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/9.1/phpunit.xsd"
         extensionsDirectory="./tools/phpunit.d">
        <testsuites>
        <testsuite name="Prophecy PhpUnit Test Suite">
            <directory suffix="Test.php">./test/</directory>
        </testsuite>
    </testsuites>
</phpunit>

The included github action automates the phar creation and adds it to the created release.

[stof]

what if we tag a prerelease tag instead of a stable one ?

[jaapio]

I think we need to discuss how to handle those, I didn't find any pre-releases in this package.
Rethinking this, we need to release every time prophecy itself is released.
This would mean that we need to connect the projects more tightly. Of course this can be automated some in some way. But before we spend to much time on this I would like to know your opinion about is.

[stof]

if the releasing of the phar needs to depend on releasing both prophecy and prophecy-phpunit, it should not be managed in the releases of the prophecy-phpunit repository itself, as that would mess things up. We should either have separate phars for each package or a separate repo managing the combined phar

[jaapio]

For example, when you would release a bugfix for prophecy people using prophecy-phpunit would need to get that patch. Seen the amount of code in this repo I don't expect too many changes. With composer this problem doesn't exist, when shipping a phar this problem does exist since all dependencies are included. I don't think phpunit can load multiple phars for a single plugin. We could investigate that. It would mean that we would deliver a prophecy phar which includes a manifest file and a prophecy-phpunit for the integration of the packages.

But maybe you are right, and a separate repo is better since it would have it's own releases.

Since this is kind of an edge case I don't want to take too much of your time. So maybe it is better to create a separate project first. And move it under the phpspec flag later if we are going to share maintenance.
That was also the mean reason for me to open an issue first before creating this PR.

[stof]

hardcoding the version as 1.0 here looks wrong to me

[jaapio]

The version here should be equal to the version of the package. When we have a release strategy for the phar releases I can have a look at how to implement this properly.

[stof]

well, isn't this PR precisely about implementing that strategy ?

[stof]

shouldn't tools be added in .gitignore ?