Inconsistency with `toTyped` and class instantiation

Consider

```pkl
class Bird {
name: String
lifespan: Int
}

// Allowed
pigeon = new Dynamic {
name = "Pigeon"
lifespan = 8
notInBird = "not in bird"
}.toTyped(Bird)

// Not Allowed
eagle = new Bird {
name = "Eagle"
lifespan = 8
notInBird = "not in bird"
}
```

How do I make the allowed example fail with an error?

`toTyped` is more lenient than class instantiation, and I'm not sure that should be the case. It might be a good default, since dynamic data can be well, dynamic and I can understand why we wouldn't want people to have to remove a bunch of non relevant data if they are working with truly dynamic data. That said, in cases like this, or when validating JSON which you want to be strongly typed with no leaked data, we are missing a `toStrictTyped` or `toTyped` with a boolean flag to ensure that it behaves _as if_ it was defined in Pkl.

Something like this is needed in my opinion both to ensure the normal course of converting from dynamic to typed can behave without surprises (e.g. `toMap().remove(x).toTyped`) and for validating _external_ schemas or data generated by other tools, since we might not want superflous data in those sources

Reproduce the two Pkl examples and compare the behavior of toTyped with class instantiation. Read the implementation and tests for dynamic conversion and class construction, then define and test strict handling of extra properties for externally supplied data.

Written by the indexing model from the issue text.