cartesian: Merge `GlobalTable` accessor (.A) and `AbsoluteIndex` accessor (.at)

[FlorianDeconinck]

Previously we design a GlobalTable (#1451) which provides a global_table_var.A(...) that works as an absolute index on the data dimensions (also work with regular Fields though it's less advertised).

We are introducing now a similar - slightly extended - concept with an absolute indexer that works as follows field.at(K=..., ddim=[...]) with ddim optional (#2276).

Those concept overlap enough to be merge into one another.

Syntax for the GlobalTable remains to be decided between:

1. global_table_var.at(ddim=[...]) - probably a more constant option but mixed data dimensions and global table
2. global_table_var.at([...]) - introduced a mixed syntax, maybe confusing
3. global_table_var.at(....) - with indices as positional arguments, mixed syntax
4. [add your idea here]

Action plan:

• Deprecate the .A use
• ADR the change and update the absolute index ADR
• Implement and check unit tests coverage

[FlorianDeconinck]

Poke @stubbiali, @oelbert, @romanc, @twicki

[stubbiali]

Thank you @FlorianDeconinck. Here are my two cents on the user interface: what about global_table.at(...), with the indices provided as positional arguments rather than as a list.

[FlorianDeconinck]

Update ticket. I guess it's a better version of .at([...]). I am a bit reluctant because then people are going to want to use this with Field, which won't work. Now of course GlobalTable and Fields are not the same - which is a good argument.

[twicki]

I am also strongly in favor of using only one interface for this. I think moving everything absolute into one bucket makes a lot of conceptual sense. I think the .A name was maybe not comprehensive enough, so .at() makes the most sense.

And since we're unifying the interface I would keep the required kwargs, so sticking with K= and ddim=. But this is just to simplify the learning curve. I think the bloat that one kwarg adds is not too big to allow for different interfaces. And generally allowing it to not be key-worded so field_4d.at(2,3) to me makes it more risky and less readable

[stubbiali]

Yes, I can see the risk of using the same accessor name with different signature between fields and global tables. I'm fine with having .at(ddim=[...]), since it improves consistency at the cost of a small increase in verbosity. I much prefer that over .at([...]).