It's too easy to target/squiggle the wrong thing in `reportDiagnostic`.

Say I have a `property: ModelProperty` and I'm writing a linter/emitter. Say something is wrong with the property type. It's invalid in the context of the emitter.

For example: In protobuf you cannot have nested arrays, so if a user writes `prop: T[][]` I want to squiggle `T[][]` with an error. I could squiggle the whole property, but squiggling just the type is something I might want to do, and in this case it feels nice. The solution is to check any array type and make sure its instantiation parameter is not, itself, an array. If it is, I'll report a diagnostic. Naturally I write this:

```ts
// declare const t: Operation;
const t = operation.type; // <- assume an instance of Cadl.Array
const arrayValueType = t.instantiationParameters![0];

if (isCadlArray(arrayValueType)) {
reportDiagnostic(program, {
code: "nested-array",
target: arrayValueType
};
}
```

This produces a difficult-to-understand result. The error is applied to the definition of Cadl.Array in compiler/lib.cadl, when what I actually wanted was to squiggle the _syntactic_ instantiation parameter.

I get this error:

`/test/.cadl/lib/lib.cadl:116:1 - error @cadl-lang/protobuf/nested-array: nested arrays are not supported by the Protobuf emitter`

when what I wanted was:

`/test/main.cadl:14:29 = error @cadl-lang/protobuf/nested-array: nested arrays are not supported by the Protobuf emitter`

Getting this result requires me to go digging inside the model property's `node` field, appropriately handling all the possible syntactic sources of the model property such as projections & spreads. It's doable, but are there or can there be helpers in the core JS API for getting the syntactic nodes I actually want to squiggle?

This same basic confusion makes it somewhat difficult to actually squiggle the argument to a decorator when it's an instance of some other type. For example: `@stream(StreamMode.Out)`. If I simply try to squiggle the value of this decorator argument (that I might store in a StateMap), I end up targeting the _definition_ of the argument, not the syntactic position of the argument, for which I have to dig through the decorator applications and find the one that corresponds to the decorator I'm looking for and then get the DecoratorArgument from that. It's very far out of the way when the `Type` itself satisfies the diagnostic `target`.