Pre-cursor to #141995 until we commit to semantics that we know will behave well.

This is more restrictive than any option listed in #141995: when we detect that a field is partially mapped, but not as the KEYWORD type - that is, e.g. idx1 has field mapped as long, but idx2 has the field unmapped - then we outright fail a query as unsupported if it uses SET unmapped_fields="load". Update: After thinking more about this, I think this is maybe too restrictive. I think being a little less restrictive is better and we should at least allow queries where such fields are not used explicitly in queries. This is essentially Option 1. from #141995. I'm unsure about permitting to use such fields in KEEP/DROP, though.

The safest way of disallowing such queries is to look for offending fields (ones that are partially mapped, but not as KEYWORD) in the mappings or EsRelations no later than after the analyzer step. I'm not sure if before, during or after the analyzer step is the best.

I don't think we need to detect cases where offending fields do end up in the mappings or EsRelation but aren't actually used. This means we'll flag a couple more queries as invalid even though they would be acceptable; but this is only a temporary limitation, anyway, until we solve #141995. Update: After thinking about this a little, that would be a little too restrictive to be useful, as the majority of queries will have partially mapped non-KEYWORD fields.