Named formula implementation, and improved handling of Defined Names generally

[MarkBaker]

This is:

- [X] a bugfix
- [X] 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

Why this change is needed?

• UTF-8 names (already extracted as a separate PR and merged)

• Defined Names are now case-insensitive

• Better support for ranges defined in the format sheetName!A1:sheetName!B2, as long as both parts reference the same worksheet (already extracted as a separate PR and merged for straight range references, support in named ranges is part of this PR)

• distinction between named ranges and named formulae

• correct handling of union and intersection operators in named ranges

• correct evaluation of named range operators in calculations

• fix resolution of relative named range values in the calculation engine; previously all named range values had been treated as absolute.

• calculation support for named formulae

• support for nested ranges and formulae (named ranges and formulae that reference other named ranges/formulae) in calculations

• Introduction of a helper to convert address formats between R1C1 and A1 (and the reverse)

• Proper support for both named ranges and named formulae in all appropriate Readers

  • Xlsx (Previously only simple named ranges were supported)
  • Xls (Previously only simple named ranges were supported)
  • Gnumeric (Previously neither named ranges nor formulae were supported)
  • Ods (Previously neither named ranges nor formulae were supported)
  • Xml (Previously neither named ranges nor formulae were supported)

• Proper support for named ranges and named formulae in all appropriate Writers

  • Xlsx (Previously only simple named ranges were supported)
  • Xls (Previously neither named ranges nor formulae were supported) - Still not supported, but some parser issues resolved that previously failed to differentiate between a defined name and a function name
  • Ods (Previously neither named ranges nor formulae were supported)

IMPORTANT NOTE: This Introduces a BC break in the handling of named ranges. Previously, a named range cell reference of B2 would be treated identically to a named range cell reference of $B2 or B$2 or $B$2 because the calculation engine treated then all as absolute references. These changes "fix" that, so the calculation engine now handles relative references in named ranges correctly.
This change that resolves previously incorrect behaviour in the calculation may affect users who have dynamically defined named ranges using relative references when they should have used absolute references.

[PowerKiKi]

We usually try to avoid adding binary files, such as NamedFormulae.xlsx, to the repo to avoid increasing its size too much. Do you think it would be reasonable to create that file from scratch, in-memory, instead of reading a pre-existing file ? or should keep the file as is ?

[MarkBaker]

I'd tried to keep the binaries as small as possible, and with as many variations and permutations for testing as possible; and I do think they're essential for testing how the Reader handles them (it's only possible to cover so much with simulated files, or with partial xml). Although the tests themselves are in Calculation, I'd considered adding specific Reader tests using those same files, with an @depends (in the end, I decided that was more awkward,and that Reader failures would trigger in the existing tests that use those files anyway). If I'd followed that route, then I'd also have felt I needed to add binaries for xls, xml, ods and gnumeric as well (ods is particularly awkward with three levels of pointers spread across two files within the zip) to cover testing those Readers as well.

I do think we need some binaries to test the Readers. We can't always create/write then read what we've written, because that doesn't verify that we can read a genuine file, only one that we've created.
I know the existing binaries are filled with a myriad of different types and styles, so one file can be used to test may different features, but felt that new files were more appropriate here because of the complexities of defined names.

My feeling is to keep them (even still tempted to add xls, xml, ods and gnumeric files as well) but with some additional Reader specific unit tests running against the same files.

[MarkBaker]

One of my big concerns was the potential BC break in the behaviour of relative ranges, if users define their named ranges as relative, expecting them to be treated as absolute... MS Excel would always have treated these ranges as relative in the generated file, so it only really affects results returned by the calculation engine itself for a getCalculatedValue() call, so I wasn't sure whether that should require a 2.0.0 release, or was minor and internal enough that it could just be part of the standard release cycle.

[PowerKiKi]

IMHO what you describe as BC break actually is bug fixing. Previous behavior was incorrect, and was changed to conform to what Excel does. I don't think that require a major version. I'd be ok with releasing this in next minor version.

[PowerKiKi]

LGTM as long as we resolve conflict