[TSP Migration][guestconfiguration] TypeSpec migrated from swagger

[HarveyLink]

This PR migrates your latest version (identified by the tag in your readme.md) of swagger to TypeSpec. We already tried our best to make sure the TypeSpec represents same as previous swagger. Since we lack the business knowledge, please validate this PR again to make sure it's functional equivalent as before. The local validation step is at Getting started | TypeSpec Azure

Besides, TypeSpec encourages to follow ARM guidelines. Therefore, some representations in your previous swagger will be fixed to follow these guidelines. When you see differences in your local validation, please keep this note in mind. Here is the list of your anti-pattern:

• Common type version is still in v1. We changed to v3.
• Same response model for one operation is pageable while for another operation is not, e.g., GuestConfigurationAssignmentReportList for GuestConfigurationAssignmentReportsVMSS_List is pageable, while for GuestConfigurationAssignmentReports_List is not.
• Some path parameters are not in the same order as that in route, e.g, this one. We do the reorder for you.

Please reach out to TypeSpec Discussions Channel if there is any help needed.

[openapi-pipeline-app]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR targets either the main branch of the public specs repo or the RPSaaSMaster branch of the private specs repo. These branches are not intended for iterative development. Therefore, you must acknowledge you understand that after this PR is merged, the APIs are considered shipped to Azure customers. Any further attempts at in-place modifications to the APIs will be subject to Azure's versioning and breaking change policies. Additionally, for control plane APIs, you must acknowledge that you are following all the best practices documented by ARM at aka.ms/armapibestpractices. If you do intend to release the APIs to your customers by merging this PR, add the PublishToCustomers label to your PR in acknowledgement of the above. Otherwise, retarget this PR onto a feature branch, i.e. with prefix release- (see aka.ms/azsdk/api-versions#release--branches).
• ❌ This PR is in purview of the ARM review (label: ARMReview). This PR must get ARMSignedOff label from an ARM reviewer.
  This PR has ARMChangesRequested label. Please address or respond to feedback from the ARM API reviewer.
  When you are ready to continue the ARM API review, please remove the ARMChangesRequested label.
  Automation should then add WaitForARMFeedback label.
  ❗If you don't have permissions to remove the label, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories.
  For details of the ARM review, see aka.ms/azsdk/pr-arm-review
  
• ❌ The required check named Swagger ModelValidation has failed. Refer to the check in the PR's 'Checks' tab for details on how to fix it and consult the aka.ms/ci-fix guide

[openapi-pipeline-app]

PR validation pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
TypeSpec	Microsoft.GuestConfiguration
Go	sdk/resourcemanager/guestconfiguration/armguestconfiguration
Python	azure-mgmt-guestconfig
JavaScript	@azure/arm-guestconfiguration
Java	com.azure.resourcemanager:azure-resourcemanager-guestconfiguration
Swagger	Microsoft.GuestConfiguration-assignments

[TimLovellSmith]

string

should nextLinks be format uri?

Can there be a typespec linter rule for this?

not really blocking but an open issue, so tagging as [ARMBlockingComment]

[TimLovellSmith]

operations metadata response shouldn't really be redeclared in every RP either. What about common types? Or justification?

[TimLovellSmith]

Can we fix this and use common types?

Real justification please if not