Report why a VIEW doesn't qualify for Record APIs

[ignatz]

Right now, when we construct a View representation we also try to derive an optional column_mapping. When we fail to do so, that's that, we move on to at least have a representation that the View exists.

The column_mapping has enough information for TB to determine if APIs are feasible. If there's none, it's too late to tell the user why. We should be able to tell the user: add a cast to make it type-safe, add a group-by to work with your set of joins, ...

There's many ways we could do this:

1. easy mode: preserve any error
2. delay analysis to when we determine suitability. It makes sense to have separate representations for what's in SQLite and what TB needs. Technically that's what View and ViewMetadata are for. We might have to store the CREATE VIEW expression in View. Note however that the admin UI table explorer, editor auto-complete, ... are operating on View::column_mapping. We should be careful not to regress there.

@kcsoft