ENG-6388 split adhoc permission into sql and sqlread

Something worth writing down here, maybe, and maybe in the other adhoc shouldAccept(), is the fact that adhoc invocations have to survive two passes through the permission system: the first time in handleRead() when they're just @AdHoc, and then the second time after they're planned and we know whether or not they're DQL, DML, or DDL....

Hmm, I just realized that there's a fail somewhere here for DDL statements.  They come in as @AdHoc, but they aren't associated with SQL or SQLREAD permissions (right?), so they're all going to get kicked out.  They emerge from the planner as catalog work...is there an ADMIN check on invoking @UpdateApplicationCatalog in nshi's stuff?  Anyway, potentially broken live DDL here, probably needs tests.