Schedule.m: remove unused Shorthands when creating READS/WRITES

[rhaas80]

This addresses https://bitbucket.org/einsteintoolkit/tickets/issues/2526/mclachlan-has-incorrect-read-declarations

[ianhinder]

Hi! I've taken a look, but the issue seems to be non-obvious, and I can't figure out all of what is going on without spending a lot more time on it. @rhaas80 since you have obviously become the expert on this issue already, would it be possible to add to the PR description a concise description of the problem, what caused it, and how the proposed fix solves it? :) The fix seems to be to remove unused shorthands from a calculation being scheduled (which doesn't seem like a bad idea), and presumably this feeds in to whether READS and WRITES statements for shorthands are generated? But shorthands shouldn't be used in READS and WRITES anyway. Further, none of this code for special cases for tmunubase variables should be in Kranc at all (clearly).

[rhaas80]

(from the linked ticket):

The READS generation is somewhat related to using Tmunu in expression as of commit hash e69182c "generate READS statement for stress_energy_state if needed" of Kranc which is in ET_2020_05_v0.

While that commit does not produce READS: TmunuBase:eTxx it queries the RequireGroups variable for their presence and that variable is the one used to generate the READS and itself generates a READS: TmunuBase::stress_energy_state. Meaning: if there is a READS: TmunuBase::stress_energy_state then RequireGroups contained TmunuBase variables and READS for them will be generated. This seems to be what happens for ML_BSSN_ADMBaseEverywhere.

[rhaas80]

Basically: all shorthands were considered all the time when generating READS / WRITES, not just the ones actually used by the calculation. A latter step pruned the shorthands to only those actually used when generating code for each calculation. So the pruning happened only when creating the code and not when creating the READS / WRITES.