Add support for Pest test generation

[faustbrian]

This makes the test framework configurable to be either PHPUnit or Pest and then generates tests accordingly, of course defaulting to PHPUnit. The implementation is mostly a bunch of if statements that alternate between 2 strings and for Pest this results in some cases for additional imports being added in the form of use function imports.

[jasonmccreary]

If I were going to merge this, I'd want to see a separate class, rather than a bunch of if statements. I think a more elegant way would be to register a PestTestGenerator which is commented out, and rename the current to PhpUnitTestGenerator. Users who wish to generate Pest tests may simply toggle the comment, much like a Laravel service provider.

[faustbrian]

@jasonmccreary I'll work on the separate classes later today or more likely tomorrow. Do you want to keep them completely separate or is an abstract class they extend fine?

[jasonmccreary]

Not sure it's worth it, but if you want.

[faustbrian]

@jasonmccreary went for duplication for now because there's so many small differences that an abstraction would be a bit hacky. Also added tests for everything that the the PHPUnit generator also tests.

[faustbrian]

@jasonmccreary something I wondered while looking at the master branch for tests. Should https://github.com/laravel-shift/blueprint/blob/master/tests/fixtures/drafts/call-to-a-member-function-columns-on-null.yaml#L22-L23 really generate an empty controller https://github.com/laravel-shift/blueprint/blob/master/tests/fixtures/tests/call-to-a-member-function-columns-on-null-TelegramControllerTest.php? I guess because there's no model, if it is expected behaviour?

Edit: I might be blind but resource: all doesn't seem to be a valid value. Seems to be either the resource shorthand or a list of specific methods.

[jasonmccreary]

This is a pretty large changeset. I'll review it over the next few days.