Support better error hints when importing data from `Parser` sources

Philliam and I were discussing JSON error reporting in Discord.

Currently, there is no `pkl import` type command I am aware of that allows us to import JSON/YAML/etc into PKL, so I am making the assumption the only way to bring in external data is through the Parser subclasses.

For this example we'll use JSON.

Consider the following

```pkl
import "pkl:json"

hidden parser: json.Parser = new {}

class JsonType {
hello: String
test: Int
}

data = parser.parse(read("file:intro.json"))
// intro.json has a type mismatch on test, it's a string instead of an int
verified: JsonType = data.toTyped(JsonType)
```

intro.json
{
"hello": "world",
"test": "oops"
}

The error I see here is:

```
Expected value of type `Int`, but got type `String`.
Value: "oops"

7 | test: Int
^^^
at thing#JsonType.test (file:///thing.pkl, line 7)
```

While this offers a value hint that I can then grep `intro.json` for to find, if you have a sufficiently large JSON file this becomes challenging to rely on for debugging purposes.

Some other configuration languages, such as cue have errors that can look like this:

```
verticals.4.categories.767.attributes.0.name: conflicting values "Absinthe style" and "Age group":
./attributes_data.cue:248:8
./categories_data.cue:119611:10
./schema.cue:39:14
./schema.cue:42:16
```

While this error message isn't fantastic either, it does identify that the problem is with the 5th vertical, and 768th attribute, which gives much higher signal on how to go about dealing with the error.

I'd love to see either the parser be smarter about reporting on errors in this fashion, even if it dynamically just references the path of the data that's problematic, or if there's a way we can `pkl import` non pkl files, as an analogue to `pkl eval -f format` so that we can get native PKL error reporting on these issues.

Start by tracing the Parser subclasses and the parser.parse/toTyped path described in the example, then compare the requested behavior with the pkl import and pkl eval -f format entry points. Done would mean choosing and documenting a concrete approach that reports the problematic external-data path or supports the proposed import workflow, with corresponding error behavior demonstrated.

Written by the indexing model from the issue text.