Representing functionally dependent data that comes from outside lazy eval

When capturing (say) a DG operator in a way that allows use of the same IR against a different mesh, arrays are encountered that have a functional dependency on the mesh, but whose computation happens outside of the lazy-evaluation world. The sizes of these arrays will often also depend on the mesh. Inter-element connectivity is a good example of this. Semantically, they're somewhere in between `DataWrapper` (which bakes fixed data into the expression graph) and `Placeholder` (which leaves inputs up for replacement).

We need (ideally unobtrusive) ways to:

- communicate to the lazy-eval infrastructure that this is data that is expected to change, and how (e.g. by introducing new shape parameters that show which bits of the shape can change)
- let the infrastructure ask the user to provide the correct values for those arrays (possibly via a callback) and infer associated shape parameters
- make a way to uniquely identify these inputs so that the infrastructure can recognize their repeated introduction. Otherwise, subgraphs depending on them may look spuriously different and require repeated compilation. Forcing some sort of global naming scheme might solve this last point, but it's a bit obnoxious, and I would prefer to avoid it.

Parametric shapes are on hold until we can come up with a design that addresses these challenges.

cc @kaushikcfd