fix: typetracer 'under-touching'

[pfackeldey]

It is relevant to force touching of columns here, because it is not necessarily ensured that a __getitem__ call, e.g. arr["x"] will add x to the typetracer report - but x is needed, otherwise the corresponding internal vector class can't be constructed.

[Saransh-cpp]

Thanks for the fix! Not sure if this is ready, but I think @jpivarski can review this the best 😄

[jpivarski]

For @Saransh-cpp's information, this is an interaction between Vector and dask-awkward (actually, Awkward Array's typetracer-touching logic) that was overlooked in theory and discovered in practice. Awkward and dask-awkward discover that a record field is needed by whether it is used in an actual calculation, not just whether it is accessed by __getitem__(x: str). This is to prevent over-touching of arrays with lots of columns—just determining that those columns exist shouldn't make a later calculation have to read those columns from disk.

In Vector, using either azimuthal coordinate causes the other to be accessed as well, just to create the vector. Perhaps a calculation uses pt but not phi (common for cuts), and then pt gets labeled as a necessary column but phi doesn't. When the calculation is being run (in a Dask worker, for instance), the pt is read from disk and the phi isn't, which causes Vector's constructors to fail.

We could have tried to fix this in two ways:

1. make Vector less strict about both fields for the azimuthal coordinates existing
2. touch both fields and force them both to exist.

Option 2 is probably better in the long run because overtouching by one field is not too bad (we worry about overtouching by thousands of fields) and if we let a Vector get constructed with one but not the other azimuthal field, who knows what other errors will happen down the road?

I like this implementation that forces touching in Vector: the _touch function is pass-through, so each time a field is accessed from an array in a Vector constructor, it gets labeled as being "touched," and there will be no issues with it at runtime. The logic is applied consistently to all fields, though I think this issue can only affect azimuthal coordinates, since that's the only sector that has more than one coordinate.

I think this is ready to merge!