MFC after:	2 weeks

(cherry picked from commit e4e91353c62e2af425061a4e56e1f24dcca2dd0f)

If somebody else holds that lock, it will likely do the work for us.
If it won't, then we return here later and retry.

Under heavy load it allows to avoid lock congestion between interrupt and
polling threads.

 - Deduce allowed address range for bus_dma(9) from the hardware version.
Different versions (CPU generations) have different documented limits.
 - Remove difference between address ranges for src/dst and crc.  At least
docs for few recent generations of CPUs do not mention anything like that,
while older are already limited with above limits.
 - Remove address assertions from arguments.  While I do not think the
addresses out of allowed ranges should realistically happen there due to
the platforms physical address limitations, there is now bus_dma(9) to
make sure of that, preferably via IOMMU.
 - Since crc now has the same address range as src/dst, remove crc_dmamap,
reusing dst2_dmamap instead.

ioat(4) should use bus_dma(9) for the operation source and destination
addresses

ioatcontrol(8) could exercise 8k-aligned copy with page-break, crc and
crc-copy modes.

I've noticed that sometimes with enabled DMAR initial write from device
to this address is somehow getting delayed, triggering assertion due to
zero default being invalid.

This allows NUMA-aware consumers to reduce inter-domain traffic.

Those functions are used by kernel, and we can't check all possible argument
errors in production kernel.  Plus according to docs many of those errors
are checked by hardware.  Assertions should just help with code debugging.

Allocate ioat->ring memory from the device domain.
Schedule ioat->poll_timer to the first CPU of the device domain.

According to pcm-numa tool from intel-pcm port, this reduces number of
remote DRAM accesses while copying data by 75%.  And unless it is a noise,
I've noticed some speed improvement when copying data to other domain.