Enhance `strictScalars` behavior to disallow defining mappings for non-existent scalar types

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

When using the `strictScalars` option introduced by #5699, I expect my scalars mappings to be strictly validated. However, it is only partially strict. It only validates that a mapping is specified for every custom scalar type, but does not validate that all scalar mappings are for valid scalar types.

For example, if my graphql schema defines a custom scalar `Foo`, but does NOT define a custom scalar `Bar`, then I would expect the following to be invalid:
```
"config": {
"strictScalars": true,
"scalars": {
"Foo": "string",
"Bar": "number" // INVALID! There is no `Bar` scalar to be mapped!
}
}
```

Current behavior is that the example config is valid, and the mappings for undefined scalar types are silently ignored.

With `strictScalars`, it would make more sense to fail with an error to make it clear that an invalid/unnecessary mapping is defined in the config (which may alert the user to possible problems to investigate if they expected that scalar to be present, etc).

**Describe the solution you'd like**
The existing `strictScalars` option should be enhanced to cause code generation to fail if any key in the `scalars` mapping config does not match:
* The name of a standard scalar type.
* The name of a custom scalar type.