Track multiple locations associated with a dyn.Value

[shreyas-goenka]

Changes

This PR changes the location metadata associated with a dyn.Value to a slice of locations. This will allow us to keep track of location metadata across merges and overrides.

The convention is to treat the first location in the slice as the primary location. Also, the semantics are the same as before if there's only one location associated with a value, that is:

1. For complex values (maps, sequences) the location of the v1 is primary in Merge(v1, v2)
2. For primitive values the location of v2 is primary in Merge(v1, v2)

Tests

Modifying existing merge unit tests. Other existing unit tests and integration tests pass.

[shreyas-goenka]

patch file used:

@@
var x expression
@@
-dyn.NewValue(x, dyn.Location{})
+dyn.V(x)

@@
var x expression
var y identifier
@@
-dyn.NewValue(x, y)
+dyn.NewValue(x, []dyn.Location{y})

@@
var x expression
@@
-dyn.NewValue(x, dyn.Location{...})
+dyn.NewValue(x, []dyn.Location{{...}})

@@
var x expression
var y expression
@@
-dyn.NewValue(x, y.Location())
+dyn.NewValue(x, y.Locations())

@@
var x expression
var y expression
@@
-NewValue(x, y.Location())
+NewValue(x, y.Locations())

@@
@@
-dyn.NilValue.WithLocation(...)
+dyn.NilValue.WithLocations([]dyn.Location{...})

[shreyas-goenka]

Once this is merged, I'll followup with the first use case for this: #1506

[pietern]

LGTM

@andrewnester Can you TAL as well?

[pietern]

This is clear, thanks.