bugfix has_columns() passing character vector of non-existing columns

[yjunechoe]

I introduced a regression in #539 when I let hard-coded character vectors bypass the tidyselect-based column resolving mechanism (in resolve_columns()). This introduced a side-effect in has_columns() (which shares the same mechanism), making it pass character vectors through without checking for existence:

library(pointblank)

# Thinks that it "found" the column `y`
data.frame(x = 1) %>% has_columns("y")
#> [1] TRUE

This happened because a column selecting expression may successfully resolve to a character vector, but the columns in the vector themselves may not exist in the data. has_columns() was missing a check for the latter.

The PR ensures that has_columns() does an additional non-lazy check for existence of the resolved columns from the data - since active = ... has_columns() ... is called during interrogate, the tbl is resolved to an actual dataframe by then.

Now all variants align in producing the expected behavior when checking for a non-existent column:

devtools::load_all()
any(c(
  data.frame(x = 1) %>% has_columns(y),
  data.frame(x = 1) %>% has_columns("y"),
  data.frame(x = 1) %>% has_columns(vars(y)),
  data.frame(x = 1) %>% has_columns(vars("y"))
))
#> [1] FALSE

I've added more unit tests to cover this nuance specific to has_columns() (so this shouldn't accidentally regress again!)

[rich-iannone]

LGTM!