Ability to describe custom actions using Attribute

[MarcEspiard]

Description

This is a very basic attempt to support custom actions (or default actions that are not coming from a Trait) through adding an Attribute to the controller method you want to appear in the output. The attribute takes decriptor class strings as arguments, which allows users full control of the output for the endpoint.

To note:

• I had to increase the PHP version requirement to >8.0 so I could use attributes. As it's a breaking change, it could be a good idea to increase it to >8.1 right now so Enums could be used in future development without another breaking change.
• I did not implement a way to supply a custom schema as you can completely overwrite the action output using your own action descriptor if you wish to do so
• the change in src/Builders/Paths/Operation/SchemaBuilder.php is a bit hacky, if the custom action is not one of the default actions (store, update, show etc..) it would just exit. The change makes it so it assumes you want the default schema for that controller. There is definitely a better way to handle this but limited by time here.
• I did not yet write documentation for this feature, I would like to discuss the PR and approach first to make sure it's accepted, I'll definitely document how to use it if the PR is OK to merge

Motivation and context

In our case, we reimplemented the Users > store action as our app needs to invite users on creation and we don't always need to create a user record in our db. We needed this package to support custom actions so our new Users > store action would be automatically documented.

How has this been tested?

Added a test case and supporting classes. Have extensively tested locally with our own production app too.

Screenshots (if appropriate)

Types of changes

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

• [x] I have read the CONTRIBUTING document.
• [x] My pull request addresses exactly one patch/feature.
• [x] I have created a branch for this patch/feature.
• [x] Each individual commit in the pull request is meaningful.
• [x] I have added tests to cover my changes.
• [ ] If my change requires a change to the documentation, I have updated it accordingly.

If you're unsure about any of these, don't hesitate to ask. We're here to help!