[mgmt] consider moving premium package out to separate folder (and use dependency on released lib)

[weidongxu-microsoft]

And only leave the azure-resourcemanager lib in resourcemanager folder (as well as other docs).

This may make it better support

1. service-serve upgrade and release
2. patch release

Things to solve (as I see for now)

1. samples is moved to folder of azure-resourcemanager
2. UserAgentPolicy uses the SDK version of azure-resourcemanager-resources, not the version of the actual lib

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[XiaofeiCao]

Yes, this should be supported before we support self-serve for premium packages.

Considerations from me:
Before we support self-serve, do we still use gulpfile.js under resourcemanager(some modifications are needed), or generate.py(same as lite)?

If we switched to use generate.py, considerations be:

1. Configurations in api-specs.json should be moved to readme.md in specs repo.
2. For premium, we should only delete files which contains Code Auto-Generate from xx. Guess we could unify this logic for lite packages as well.
3. For resources, we use --preserve to preserve generated code when generating for deployments. We may need the same parameter for generate.py.
4. How does service learn about the generation notes in api-specs.json? e.g. ConfigurationUtils updates for redis. This should not be a problem before self-serve.

[weidongxu-microsoft]

For (3), we may delay the resources libs, as it probably not easily convertible to TypeSpec. (even if they converted it, we'd need to do "combine output of multiple tsp compile to same package)

For (4), we may put some doc in folder that asks service to "self-serve" by handling the "post codegen" (aka, the process may not be fully automatic).

[XiaofeiCao]

As offline discussed, for monthly premium release, we'll only release azure-resourcemanager.
For other packages, we need to:

1. Inform service to release before patch release(usually third week of the month).
2. If we do new handwritten features, we should release right after PR merge. For packages being dependencies of other packages(e.g. storage), we should avoid release after patch release, or do manual patch release for dependent packages as well(e.g. Compute)