Ranges can be UDTs with syntactic sugar for constructing them

Yes, I think ranges really are just UDTs with syntactic sugar for constructing them. In old Q#, you could already manually "update" any range field:

```qsharp
function UpdateRangeStart(r : Range, start: Int) : Range {
return start..RangeStep(r)..RangeEnd(r);
}

function UpdateRangeStep(r : Range, step : Int) : Range {
return RangeStart(r)..step..RangeEnd(r);
}

function UpdateRangeEnd(r : Range, end : Int) : Range {
return RangeStart(r)..RangeStep(r)..end;
}
```

So I don't see any problem with `w/` being sugar for those functions. In fact I'd actually recommend we refactor the compiler to literally define `Range` in the core library:

```qsharp
newtype Range = (Start : Int, Step : Int, End : Int);
```

and lower range expressions into constructor calls referencing the core type. That would remove all the special casing for "primitive" fields.

_Originally posted by @samarsha in https://github.com/microsoft/qsharp/issues/308#issuecomment-1548157593_

Review issue #308 and the proposal for treating Range as a core-library UDT with w/ and range-expression syntax as constructor sugar. Trace the compiler’s current special handling for Range fields, then define the scope and compatibility criteria for removing that special casing; done means the proposed representation and lowering behavior are implemented and validated.

Written by the indexing model from the issue text.