configs: Hint for a misplaced top-level required_providers block

With provider dependencies now appearing inside a nested block, it seems
likely that configuration examples showing dependencies out of context
will sometimes mislead users into thinking that required_providers is
toplevel.

To give better feedback in that situation, we'll produce a specialized
error in that case hinting the correct structure to the user.

configs/parser_config.go

@@ -92,6 +92,15 @@ func (p *Parser) loadConfigFile(path string, override bool) (*File, hcl.Diagnost
 				}
 			}
 
+		case "required_providers":
+			// required_providers should be nested inside a "terraform" block
+			diags = append(diags, &hcl.Diagnostic{
+				Severity: hcl.DiagError,
+				Summary:  "Invalid required_providers block",
+				Detail:   "A \"required_providers\" block must be nested inside a \"terraform\" block.",
+				Subject:  block.TypeRange.Ptr(),
+			})
+
 		case "provider":
 			cfg, cfgDiags := decodeProviderBlock(block)
 			diags = append(diags, cfgDiags...)
@@ -193,6 +202,12 @@ var configFileSchema = &hcl.BodySchema{
 		{
 			Type: "terraform",
 		},
+		{
+			// This one is not really valid, but we include it here so we
+			// can create a specialized error message hinting the user to
+			// nest it inside a "terraform" block.
+			Type: "required_providers",
+		},
 		{
 			Type:       "provider",
 			LabelNames: []string{"name"},

configs/testdata/error-files/required-providers-toplevel.tf

@@ -0,0 +1,9 @@
+# A top-level required_providers block is not valid, but we have a specialized
+# error for it to hint the user to move it into a terraform block.
+required_providers { # ERROR: Invalid required_providers block
+}
+
+# This one is valid, and what the user should rewrite the above to be like.
+terraform {
+  required_providers {}
+}