Improve validation to catch use of armID as name

[theunrepentantgeek]

Describe the current behavior

A user inadvertently set up a resource reference this way:

  workspaceResourceReference:
    group: operationalinsights.azure.com
    kind: Workspace
    name: /subscriptions/<rest of the ARM ID>

This didn't work, as the expected structure for references using ARM IDs is this:

  workspaceResourceReference:
    armId: /subscriptions/<rest of the ARM ID>

Describe the improvement

The error message was accurate, but not as informative as it could be.

I'm wondering if we could improve the error handling to detect the case where something goes wrong and name has been populated with something that looks more like an armID than it does like a name.

Perhaps something like some of the errors from git where it gives a suggestion. For example, what if the error included name looks like it might be an ARM ID; did you mean armID: /subscriptions/<rest of the ARM ID> ?

[matthchr]

We can also consider doing more coverage of cross-resource references in a hand-held end to end sample

[matthchr]

This seems like something that's probably pretty easy to do?

This name:
name: /subscriptions/<rest of the ARM ID> is a Kuberentes name, so we can verify that it matches expected Kubernetes naming rules.

Also can, if we see /subscriptions point users at the ARM ID field