Resolve ml-queries from directory

[aeisenberg]

Previously, there was a bug where quick eval queries would crash when
the eval snippet is in a library file.

The problem was that the codeql resolve queries command fails when
passed a library file. The fix is to avoid passing the library file at
all. Instead, pass the directory. This is safe because the resolve
queries command only needs to know which query pack the file is
contained in. Passing in the parent directory is the same as passing in
a file in this particular case.

This PR removes a previous workaround implemented here: #1412. This previous workaround simply disabled ml packs for quick eval.

Replace this with a description of the changes your pull request makes.

Checklist

• [n/a] CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
• Issues have been created for any UI or other user-facing changes made by this pull request.
• [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

[aeisenberg]

I don't think this needs a changelog entry since we didn't previously mention that ml models won't be used for quick evals in libraries (which is all this PR enables).

[edoardopirovano]

LGTM

[henrymercer]

This should always work because the command ultimately calls codeql resolve queries --format startingpacks, and the parent directory of a query will always live in (or be) the same pack as that query lives in. The fact we need it probably indicates that something isn't quite right with the design here — I think we really want a command that takes an extension of queryspecs that includes qll files. But I think it's good enough for our current needs.

[aeisenberg]

Yes. I think there's something we could do in the resolve queries command itself, and I started working on that, but it just made the command more complicated and more confusing. I didn't want to make this change to the codeql command for this one edge case. If we see more instances of this happening, then we may want to look into it.