Reorder the guidelines so the error contract is clearer

Author: tg-msft

azure/Guidelines.md

@@ -302,8 +302,6 @@ There are 2 kinds of errors:
 
 :white_check_mark: **DO** ensure that the top-level error's `code` value is identical to the `x-ms-error-code` header's value.
 
-:white_check_mark: **DO** document the service's error code strings; they are part of the API contract.
-
 :white_check_mark: **DO** provide a response body with the following structure:
 
 **ErrorResponse** : Object
@@ -347,6 +345,8 @@ Example:
 
 :heavy_check_mark: **YOU MAY** group common customer code errors into a few `x-ms-error-code` string values.
 
+:white_check_mark: **DO** document the service's top-level error code strings; they are part of the API contract.
+
 :heavy_check_mark: **YOU MAY** treat the other fields as you wish as they are _not_ considered part of your service's API contract and customers should not take a dependency on them or their value. They exist to help customers self-diagnose issues.
 
 :heavy_check_mark: **YOU MAY** add additional properties for any data values in your error message so customers don't resort to parsing your error message.  For example, an error with `"message": "A maximum of 16 keys are allowed per account."` might also add a `"maximumKeys": 16` property.  This is not part of your API contract and should only be used for diagnosing problems.