Mutate the RSS stuff a whole lot more in preparation for correctly
handling situations where the NIC isn't hashing things for us.

* Fix a bug where I was allowing a 2-tuple hash to be okay for
  a hash that required a 4-tuple.  If the NIC software-hashes
  2 tuple but RSS wants 4-tuple, we need to software hash.
* Remove the direction parameter from rss_proto_software_hash_v4() -
  for now it's up to the caller to choose the correct local/remote
  parameter ordering.
* Add a new function to do software hashing of an mbuf, which
  handles checking if an existing hash is OK and hashing as
  appropriate.
* netisr won't punt frames to the m2cpuid routine if the
  netisr is direct dispatch, so force it to be deferred for
  now.  Forcing it to dispatch means that ..
* .. now the receive path both handles incorrectly and non-hashed
  frames.

I've tested this on both ixgbe and em.  em doesn't use the
hardware RSS bits, so it's forced to do a hash.

Note that now that deferred dispatch is being used, the unfortunate
performance issue with UDP has crept up again.  The userland process
is totally starved from any runtime.