mapSchema carries over schema validation state

**Describe the bug**

A schema that is explicitly assumed to be validated using the `assumeValid` flag or a schema that has actually been validated is marked as such using an internal flag.

mapSchema carries over this flag to the new schema. This is debatable in the former case (when the schema is explicitly marked as assumeValid, presumably to ensure that the validation step is skipped), but is definitely incorrect in the latter scenario.

**To Reproduce**

This was surfaced in #4066 where a schema will fail validation when incompletely pruned, but only fails when using graphql-executor. This is presumably because when using graphql-executor, we get a different order of test execution, and the propertySchema has not been validated elsewhere. If you step through the test code line by line, just running the failing test, the test failed even when using the graphql-js execute function!

**Expected behavior**

This flag should not be carried over automatically. This would be the expected behavior when the flag is not set explicitly. The flag is set explicitly in cases where the schema creator wants to skip validation altogether. Whether validation should also be skipped for any schemas mapped for the original schema is unclear, and could differ in each case. This should probably be an argument for the executor, and should be raised as such in graphql-js.

Start at mapSchema and reproduce the validation-order problem described in #4066, comparing graphql-executor with graphql-js. Trace how the validation state is transferred to the mapped schema and determine the intended handling of explicitly set assumeValid state. Done means the state is not carried over automatically and the incompletely pruned schema has regression coverage.

Written by the indexing model from the issue text.