Bumps [github.com/hashicorp/packer-plugin-sdk](https://github.com/hashicorp/packer-plugin-sdk) from 0.5.1 to 0.5.2.
- [Release notes](https://github.com/hashicorp/packer-plugin-sdk/releases)
- [Changelog](https://github.com/hashicorp/packer-plugin-sdk/blob/main/CHANGELOG.md)
- [Commits](hashicorp/packer-plugin-sdk@v0.5.1...v0.5.2)

---
updated-dependencies:
- dependency-name: github.com/hashicorp/packer-plugin-sdk
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Make the post-processor able to create vagrant box from M1 macOS images.

The Vagrant Cloud API responds to the creation of resources with `200
OK` and the create version and create provider steps only check for this
status code. However according to RESTful conventions the expected
response for resource creation would be `201 Created`. From MDN[1]:

    The HTTP 201 Created success status response code indicates that the
    request has succeeded and has led to the creation of a resource

and restfulapi.net[2]:

    HTTP Status 201 indicates that as a result of HTTP POST request, one
    or more new resources have been successfully created on the server.

To ensure that the post-processor works with alternative implementations
that provide Vagrant Cloud like functionality, but adhere to RESTful
conventions, it would be useful if the response code checks allowed a
`200` status code.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
[2] https://restfulapi.net/http-status-201-created/

The post-processor, when consuming a parallels artifact, checks for the
presence of a pvm or macvm file from the files of the artifact
received, and copies it in the output box for vagrant to use later.
However, if the artifact does not contain a compatible file, the
post-processor does not error, and instead returns a success, leading to
an unusable box being produced.

To avoid this, we count the files copied, and if none were, the box will
be unusable, so the post-processor errors now.

The original regex had multiple occurrences of a `.+?' pattern, which is
essentially the same as a `.*', so we replace the former by the latter
for clarity.

Additionally, since the beginning of the path does not interest us, we
can ignore it from the regex, and only start matching once we have found
what's interesting for us, further simplifying the expression.