PERF: avoid accessing has_dropped_na
When profiling `q1` in the "pandas_queries" from https://github.com/pola-rs/tpch I found the single check to has_dropped_na took 6.5 seconds, 15% of the total runtime.  Turns out we only need has_dropped_na in transform cases, so this PR just avoids accessing it unless it is necessary.

cc @rhshadrach since I think you introduced has_dropped_na.  This seems like something we should be able to improve upon.  Maybe by checking for -1s at the point where we create the codes rather than after we have them?
> When profiling `q1` in the "pandas_queries" from https://github.com/pola-rs/tpch I found the single check to has_dropped_na took 6.5 seconds, 15% of the total runtime.

Looking at the implementation of has_dropped_na, I'm surprised by this. I'd like to dig into this further - it's a bit hard to discern a reproducible example for this from the link. Do you have anything in this regard? (I can also poke around more). hmm thats a good point.  in retrospect I bet its the `self.group_info` access that is slow, not the `<0).any()` part.  closing.