Update Cadl sample project (#22229)

* Update Cadl sample project

- Move sample project under specification folder
- remove project.json file from individual project
- Add global project.json file under specifications folder

Author: weshaggard

custom-words.txt

@@ -2675,3 +2675,4 @@ interactivequery
 tmpfs
 npipe
 Tmpfs
+widget's

documentation/cadl-sample-project/specification/contosowidgetmanager/Contoso.WidgetManager/package.json

@@ -77,7 +77,7 @@ The folder name should correspond to the RP-name, but dropping the leading "Azur
 
 ### Packages
 
-All services and service family libraries are modeled as Cadl packages, since you must install supporting librarie for proper tooling support. Per this proposal, all packages defined in the repo would be **unpublished**. Only packages in `cadl-azure` would be published. We will annotate the packages with `"private": true` in the `package.json` file to prevent publishing these to npm.
+All services and service family libraries are modeled as Cadl packages, since you must install supporting librarie for proper tooling support. Per this proposal, all packages defined in the repo would be **unpublished**. Only packages in `cadl-azure` would be published. 
 
 All packages defined in this repo would use the `@cadl-api-spec` scope and use a lowercased, dashed form of the service namespace (ex: `@cadl-api-spec/azure-storage-blob`).
 
@@ -86,7 +86,6 @@ All packages defined in this repo would use the `@cadl-api-spec` scope and use a
 Each package should have the following minimum structure:
 
 - `cadl-project.yaml`
-- `package.json`
 - `main.cadl` file
 - Supporting `*.cadl` files
 - `examples/` folder for example JSON files
@@ -95,11 +94,12 @@ Authors may use folders as desired for organizing cadl files.
 
 Additionally, packages which wish to define custom linter rules or otherwise use TypeScript must place any `*.ts` files under a `src/` folder. Within the `src/` folder, the author may use as many subfolders as desired for organizing code.
 
-To distinguish between folders which define a service, an SDK, or both, one can look to the `cadl-project.yaml` and/or the `package.json`.
+To distinguish between folders which define a service, an SDK, or both, one can look to the `cadl-project.yaml`.
 
 - SDKs will take dependencies on the `@azure-tools/cadl-dpg` library, as well as SDK-specific emitters such as `@azure-tools/cadl-python` and configure their options within `cadl-project.yaml` but the emitter version should not be configured within `cadl-project.yaml`, and it should be configured globally in SDK repo instead.
 - SDKs _may_ have a sidecar file to customize how the SDK is shaped. Folders that describe service definitions only will not have a sidecar file. _Note: the absence of a sidecar does not mean that a folder does not describe an SDK, but the presence of one means it is an SDK._
 - Services will take a dependency on `@azure-tools/autorest` and configure the emitter in `cadl-project.yaml`.
+- Services should **not** have a `package.json` directly in the cadl directory as they all should be using the global `package.json` in the root specification folder for installing any dependencies needed. 
 
 ## Service Family Libraries
 
@@ -113,7 +113,7 @@ import "../Contoso.WidgetManager.Shared";
 
 While this would permit services from importing any service library described in the specs repo, as a matter of policy we should probably avoid that and have tooling to detect this scenario. Service family libraries **should** use versioning decorators and spec packages should reference them as versioned dependencies. Tooling would need to ensure that changes to service family libraries does not result in unexpected changes to any service version. One way to do this would be to diff the projection of the service versions on the `main` branch against the projection of the service versions that result from the change.
 
-We treat the shared library as a sibling with other packages within the service family. This is similar to what we currently do for services that have a "Shared" package and would allow an arbitrary number of shared packages. A shared library folder should not contain `cadl-project.yaml` and `package.json` as it's not requried to be released. See [Sample Project](#sample-project) for reference.
+We treat the shared library as a sibling with other packages within the service family. This is similar to what we currently do for services that have a "Shared" package and would allow an arbitrary number of shared packages. A shared library folder should not contain `cadl-project.yaml` as it's not requried to be released. See [Sample Project](#sample-project) for reference.
 
 ```
 -> specification
@@ -137,7 +137,7 @@ Here's an example of how Cognitive Services might use multiple shared libraries:
 ```
 ## Sample Project
 
-Here's a [cadl-sample-project](./cadl-sample-project) to demonstrate the files and folders supposed to be included when check in to this `azure-rest-api-specs` repository.
+Here's a [cadl-sample-project](../specification/contosowidgetmanager) to demonstrate the files and folders supposed to be included when check in to this `azure-rest-api-specs` repository.
 
 # Spec Versioning
 

documentation/cadl-structure-guidelines.md

@@ -4,7 +4,7 @@
   "parameters": {
     "widgetName": "name1",
     "api-version": "2022-11-01-preview",
-    "body": {
+    "resource": {
       "manufacturerId": "manufacturer id1",
       "sharedModel": {
         "tag": "tag1",