Add optional user-specified comm_tag to operators

[majosm]

...for disambiguating multiple operator calls within a single compiled function.

Questions for the review:

• Is the scope and purpose of the PR clear?
  • The PR should have a description.
  • The PR should have a guide if needed (e.g., an ordering).
• Is every top-level method and class documented? Are things that should be documented actually so?
• Is the interface understandable? (I.e. can someone figure out what stuff does?) Is it well-defined?
• Does the implementation do what the docstring claims?
• Is everything that is implemented covered by tests?
• Do you see any immediate risks or performance disadvantages with the design? Example: what do interface normals attach to?

[MTCam]

Neat solution.

[majosm]

(Verified in the multiple-volumes-mpi.py example of #726.)

@matthiasdiener @inducer Does this look OK to you guys?

[inducer]

LGTM. Two thoughts I had while scrolling:

• There's a potential disaster here if someone were to forget to pass the tags through a level. We should think of a way to give the user a chance to examine the set of tags to make sure it matches expectations. Detect duplicated communication tags inducer/pytato#357 Make a way for the user to examine the set of distributed communication tags inducer/pytato#358
• Given the number of kwargs in some of those routines, you want to start kwarg-only-ing some of those. (I saw that done in one place already 🎉)