Allow scalarToLiteralMapping to declare TS type for extended scalar type

[CarsonF]

As far as I've been able to deduce there's no need to jump to the type's first base type to determine the TS literal value.
This is because the function already jumps to the type's material_id, which has already worked out the "base concrete type".
https://github.com/edgedb/edgedb-js/blob/dfcf3d48f74fd78c47146b505a4e942d4b33d849/packages/driver/src/reflection/queries/types.ts#L165-L169
https://github.com/edgedb/edgedb-js/blob/dfcf3d48f74fd78c47146b505a4e942d4b33d849/packages/driver/src/reflection/queries/types.ts#L139-L144
This change resulted in no changes in my generated query builder, schema, or query files, so I'm fairly confident in it. Though not 100% and I don't know the difference between bases and ancestors (maybe they are the same for ScalarType?).

---

With that change in place I was able to add the logical change: allowing scalarToLiteralMapping to declare scalars that should use their own TS literal type instead of the base type.
My use case is this:

scalar type RichText extending json;

scalarToLiteralMapping['default::RichText'] = { type: 'TSShapeOfRichText' };

[scotttrinh]

Yeah, these changes make sense to me, thanks for investigating!