fix(rds): AWS validation errors, table aliases and template where clauses

[bentsku]

A bug report flagged that malformed input to the rds query builders raises a raw TypeError, which surfaces as an opaque internal error rather than a message naming the offending key. This raises AWS's validation error instead, and closes the input cases where we diverged.

AppSyncUserError moves out of index.js into errors.js so rds/index.js can throw it without an import cycle, and every message the builders raise now uses it.

Behaviour, recorded from EvaluateCode:

• Roughly thirty inputs that produced a TypeError, silently wrong SQL, or the wrong wording now produce AWS's message: nullish comparison values, malformed and non-array orderBy, non-string column names, missing or non-object values, unsupported condition operators, non-boolean attributeExists, non-numeric limit/offset, and malformed statement payloads.
• columns shares returning's validation, ordering included — a malformed list is reported before MySQL's lack of RETURNING support.
• A non-string orderBy dir sorts ascending instead of being rejected; v0.1.4 was stricter than AWS here. limit and offset are coerced to numbers.
• New rendering: a where clause may be a sql tagged template, and a table may be named by an alias object ({ persons: "p" } → "p" as "persons", in all four statement types). Both were reachable inputs that previously crashed or rendered garbage.
• Two messages reproduce a Java exception AWS leaks from its own implementation; a comment marks each.

Validation errors carry the errorType Code, which is how AppSync attributes a fault in the resolver code itself. Without it a consumer cannot tell a rejection raised by the library from an error a resolver author raised deliberately with util.error, since the two are otherwise identical.

The test harness now strips the code.js:<line>:<col> source position AWS prefixes a thrown message with, so an error is snapshotted like any other result. The nineteen assertions the previous two PRs had to pin as string literals are recorded snapshots now, and every parity claim in the rds suite is compared against AWS. The exception is three tests covering the errorType above: EvaluateCode reports an error as a bare message and never mentions errorType, so there is nothing to record and they pin our own contract instead.

Bumps to v0.1.5, with a changelog line covering #284's conditions and alias as well since that release was not cut.