Add more detailed instructions in the generic-subscription.md for the subscription configuration files

[autocloudarc]

Is your feature request related to a problem? Please describe.

After following the instructions in the .../docs/archetypes/generic-subscription.md file on how to create and maintain the subscription configuration parameter files, I discovered that some of the tasks required were missing and may have just been implied.

I feel it would be better to make these more explicit for readers to reduce any ambiguity about which parameters and properties should be modified from the default templates, such as: default-subscription-id_generic-subscription_canadacentral.json

Describe the solution you'd like

1. Suggest updating the "serviceHealthAlerts": {"receivers": {"app": [], "email": []} } properties with specific email addresses and phone numbers as required.

2. Suggest updating the "securityCenter": {"value": {"email": "", "phone": ""} properties with specific email and address values.

3. Suggest updating the two "subscriptionRoleAssignments: {"value": ["securityGroupObjectIds": []]}" properties with specific object ids.

4. Suggest updating the "resourceTags": {"value": {"ClientOrganization": "","CostCenter": "", "DataSensitivity": "", "ProjectContact": "", "ProjectName": "", "TechnicalContact": ""}" values to reflect specific, any additional name value pairs of tags required as well as to customize default resource name values with any specific preferred naming conventions.

5. Instruct readers that the subscriptionId segment value of the "hubNetwork": {"value": } string, must be updated from it's default value to the specific hubNetwork subscriptionId that was deployed previously so this subscription as a spoke can be peered to it.

6. Suggest that the rest of the segments for the virtualNetworkId string must also match the actual resources that were deployed previously, such as the name of the resource group, in case a different prefix besides pubsec was used to conform to a specific and preferred naming convention or organization prefix, or the default VNET name of hub-vnet was also changed to something else, again based on a specific and preferred naming convention that may have been used before when deploying the actual hub VNET.

Describe alternatives you've considered
No alternatives to consider, just to update the README.md file to include this guidance.

Additional context
I would be happy to contribute to updating the documentation with a PR since I've already taken the screenshots shown.

Thank you all for an amazing deployment experience. :-)

[SenthuranSivananthan]

Great feedback @autocloudarc. Do you want to work on improving the archetype documentation to reflect this?

Content would be added to https://github.com/Azure/CanadaPubSecALZ/blob/main/docs/archetypes/generic-subscription.md

[autocloudarc]

Yes @SenthuranSivananthan. That would be great. Working on it now...