Test AddressHelper::convertFormulaToA1

[ndench]

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

• Changes are covered by unit tests
• Code style is respected
• Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• CHANGELOG.md contains a short summary of the change
• Documentation is updated as necessary (not necessary)

Why this change is needed?

As discussed in #2076, the `AddressHelper::convertFormulaToA1 function was not tested. This is quite a logically intensive function and as a result I actually identified a bug while writing the tests. The bug was identified with this test:

1) PhpOffice\PhpSpreadsheetTests\Cell\AddressHelperTest::testConvertFormulaToA1FromR1C1Relative with data set #5 ('=E3-E7-G5-C5-E5-5', '=R[-2]C-R[2]C-RC[2]-RC[-2]-RC-5', 5, 5)
PhpOffice\PhpSpreadsheet\Exception: Invalid R1C1-format Cell Reference, Value out of range

As you can see from this regex101 example the old regex fails for relative R1C1 conversion when the column is the current column and the reference is followed by a minus sign, eg R[-2]C-R[2]C.

I updated the regex to use non-capturing groups to enforce that the R or C is followed by either:

• A positive number
• A number inside square brackets with an optional negation sign

Which you can see from this regex101 example that it extracts the references correctly.

I decided against splitting this function into two different functions (as it handles both R1C1 and SpreadsheetXML formats) in this PR as I thought it best to get some functioning tests first. Then we can split it up later.

[MarkBaker]

As with our previous PR, a class constant is useful for regexp, even if it's only used in the one place.... there's a number of other regexp features (e.g. the /x switch) that can be used to help document them, and having them as a class constant is the easiest place to do this

[ndench]

Yep, good point. I mainly kept it here so you could see the change I made easily. But it's certainly better as a constant. Fixed up 👍

[MarkBaker]

Just as a useful little technique for your data provider array.... using associative indexes for each test can make it easier to recognise which tests are failing, and also has benefits if you report tests using additional phpunit tools
e.g.

return [
    'Sum with relative range' => ['=SUM(E1:E5)', '=SUM(R1C5:R5C5)'],
    'Sum with relative range and additional value' => ['=SUM(E1:E5, D5)', '=SUM(R1C5:R5C5, R5C4)'],
];

When a test does fail, it's reported by the name that you've given it, rather than simply it's offset number (with data set #5), which can make it a lot easier to identify in large data providers.

And not every test case needs to be named, so the array can be a mix of enumerated and associative

[ndench]

Ah yes, I completely forgot about this. I've added in proper names for each data set.

[MarkBaker]

Have you ever had one of those moments, when reviewing a PR, when you notice a bug in the code... not a new bug, not one that you've introduced, but something that has been in the code for years, and nobody has ever noticed.... one that I introduced when I created the original SpreadsheetML Reader.

Consider the formula

of:=1.23+2.34

or

of:=[.D3]+[.F7]+[.G4]+[.C6]+5.67

in a SpreadsheetML file... it'll process cleanly and with no error through the convertor, but it won't be the same formula.

Don't worry about it; I'll implement a fix as a separate PR, with some additional unit tests.... I'm just very, very annoyed at myself

[ndench]

Ah yes, I can say I've definitely had that before 😂. Should we merge this PR then? So that we can add that as a unit test case? I'm happy to do it if you'd like a hand?

I've rebased this onto master as well, so that it's not blocked.