migrate to track2 azure go sdk

[HuShaoRu]

add v2 folder, which uses the latest version of Azure SDK for Go (known as track2), as old version of Azure SDK for go (known as track1) is deprecated and no longer recieving support.
The v2 folder looks like a standalone package, which also uses package name skewer, only shares go.mod and go.sum with current package. check the usage in v2/README.md or v2/example/example.go

I copied the original go codes to v2 and refactored on it. keep most old codes and only work on necessary changes:

• use armcompute.ResourceSKUsClient instead of compute.ResourceSkusClient, in interface.go, client.go, cache.go
• use armcompute.ResourceSKU instead of compute.ResourceSku, in sku.go, wrap.go
  as track2 List returns []* instead of [], and some properties use []* instead of *[], I changed some usages (for example, nil check) of those models.
  I don't change SKU here, so SKU is not pointer and data is still []SKU but not []*armcompute.ResourceSKU, which might be different from sdk pattern.

golangci-lint run --fix might give some lint issues. as the linter settings are so old and even fail for main branch, I don't fix them.

[HuShaoRu]

several questions:

1. should we merge to main? we can also create another branch named dev or v2 or track2 , just need to tag it . (in pull request I can only merge into an existing branch) Or we can use a subfolder v2 there.
2. should SKU be armcompute.ResourceSKU or *armcompute.ResourceSKU? in track2 sdk, the items in [] are always poiners
3. which armcompute version should we use, the latest version (now it's v7)? the api version doesn't change, but we need to use the right datamodel/client version.

[CustardTart32]

If we want to maintain support for the track 1 skewer module as well, it would be best to either create a /v2 folder or merge this PR to a v2 branch instead of the main branch.

If we decide to drop support for track 1, merging to main would be fine.

[matthchr]

several questions:

1. should we merge to main? we can also create another branch named dev or v2 or track2 , just need to tag it . (in pull request I can only merge into an existing branch) Or we can use a subfolder v2 there.
2. should SKU be armcompute.ResourceSKU or *armcompute.ResourceSKU? in track2 sdk, the items in [] are always poiners
3. which armcompute version should we use, the latest version (now it's v7)? the api version doesn't change, but we need to use the right datamodel/client version.

Answers below in my opinion:

1. I think I prefer a v2 subfolder. I'm open to the branching as mentioned if folks really prefer that but v2 subfolder keeps things simple and still allows us to patch old skewer if we needed to for some reason easily (I know we can in the other approaches but it's not as easy).
2. IMO avoid ptrs if not needed. The SDK has them and I understand why it has them but they make everything worse =) edit: After looking further actually I see we're just aliasing the types so actually everything inside is still ptrs, so I care less about this now.
3. v7 is fine I think.

[matthchr]

Had few more comments, but overall LGTM and probably at this point reasonable to move to v2 subfolder?

[HuShaoRu]

move the files to new folder v2.
v2 looks like a standalone package, only shared go.mod and go.sum with current package. v2 also use package name skewer. To use it, change "github.com/Azure/skewer" to "github.com/Azure/skewer/v2" and make necessage changes on client and sku model. (see v2/README.md or v2/example/example.go for example)