Upgrade iguana for PHP 8 compatibility

[patdel0]

This PR resolves the deprecation warning, by upgrading iguana to the latest version:

Return type of Dxw\Iguana\Value\ArrayBase::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

How to Test

1. Install and activate this plugin
2. Navigate to wp-content/plugins/govuk-components-plugin
3. Checkout this branch chore/update-composer-dependencies
4. Confirm the deprecation warning is no longer present

[jkeasley]

LGTM - can you check why the unit tests and php-cs-fixer aren't completing before merging though

[snim2]

LGTM - can you check why the unit tests and php-cs-fixer aren't completing before merging though

I notice these are for PHP7.2 which we no longer deploy. We should probably add a PHP 8 to the matrix and remove 7.2

[patdel0]

@jkeasley The 7.2 checks have been removed from the workflow, hence why they aren't running (?). I expect that once the revised workflow is integrated, these checks will no longer be part of future merges/pushes.
5a10079
Is my assumption incorrect?

[snim2]

@jkeasley The 7.2 checks have been removed from the workflow, hence why they aren't running (?). I expect that once the revised workflow is integrated, these checks will no longer be part of future merges/pushes. 5a10079 Is my assumption incorrect?

Ah, they are listed in some branch protection rules, so I'll remove them, but we should still add a PHP8 to the matrix (then I'll add those rules in)

[snim2]

I'm not sure about this TBH. There are two places where we can add the platform, one where you can use || and one where you cannot. What happens here if we try to run composer install in 7.4?

[patdel0]

Sorry, I thought I replied to this already.

It seems to work okay on my end when testing it on saluki 7.4.
Regardless, I changed it to match what we did in iguana

[snim2]

Since this is a library package, and intended to be installed as a dependency, I would not expect to have a composer.lock file in the repo (I'd expect it to be in .gitignore). @jkeasley that's our usual convention, right?

[jkeasley]

@snim2 yeah, I'd expect the composer.lock to be in .git-ignore

[patdel0]

@snim2 Would you like me to rebase/resolve the conflicts before giving it another look?