Move all JS packages under an sdk folder

[weshaggard]

Based on https://github.com/Azure/azure-sdk/blob/master/docs/engineering-system/repo-structure.md which is trying to add some consistency across our azure-sdk repo's we should move all the packages from packages\@azure and put them under an sdk directory. Like:

sdk\<service name>\<package name>\README.md
sdk\<service name>\<package name>\*src*
sdk\<service name>\<package name>\*test*
sdk\<service name>\<package name>\*samples*

Examples:

sdk\keyvault\arm-keyvault\README.md
sdk\keyvault\arm-keyvault\src
sdk\keyvault\arm-keyvault\test
sdk\keyvault\arm-keyvault\samples
sdk\keyvault\keyvault\README.md
sdk\keyvault\keyvault\src
sdk\keyvault\keyvault\test
sdk\keyvault\keyvault\samples

A few things that we know needs to be updated when we make this restructuring:

1. The README files in the azure-rest-api-specs repo needs to be updated so the autorest tools can still function. We also need to stage the updates so that we don't disrupt too many in-flight PRs.
2. The build/CI scripts need to be updated so they understand the new structure. We should probably stage it so it understands both structures in the short term to enable incremental moving and minimize disruptions.
3. The documentation configuration system needs to be updated so it knows the new location of the README files and we don't break the documentation automation process.

[weshaggard]

To help stage this move we are going to do it in stages:

1. azure-template -> Done
2. client libraries, starting with the ones that @AlexGhiondea owns. @AlexGhiondea can you please confirm the list? I believe it is keyvault, servicebus, eventhubs, and storage are there more?
3. everything else which is mostly management libraries. @salameer is @daschult the right person to work with to figure out a plan to move the other libraries in this repo?

[weshaggard]

@salameer @daschult @sergey-shandar - @KarishmaGhiya is now at a point where we want to discuss a strategy for moving the management plane libraries into the new structure. What would you guys suggest for doing this move?

[kpajdzik]

A few things that we know needs to be updated when we make this restructuring:

1. The README files in the azure-rest-api-specs repo needs to be updated so the autorest tools can still function. We also need to stage the updates so that we don't disrupt too many in-flight PRs.

I think the only concern are currently opened PRs. Our scripts are quite flexible in terms of README directory so that shouldn't be an issue.

2. The build/CI scripts need to be updated so they understand the new structure. We should probably stage it so it understands both structures in the short term to enable incremental moving and minimize disruptions.

We need to modify the CI to take autoPublish property from package.json. We've added it to all RM package.jsons some time ago but CI isn't updated yet. Issue created for that: #2020

3. The documentation configuration system needs to be updated so it knows the new location of the README files and we don't break the documentation automation process.

That we need to coordinate with DOCS team. I think we need to reiterate once we know how to tackle #1.

[KarishmaGhiya]

@kpajdzik
I will be working on different services one-by-one. For minimal disrupt to PRs, you can also suggest me to start with some service that currently doesn't have a PR out. You can also specify the order of services/packages in which you would prefer me to work on, so that there are minimal conflicts. Also after I make the changes, I will ask the concerned people for that service to review the PR.