Anti-Affinity groups should allow memberships consisting of affinity groups

Related to https://github.com/oxidecomputer/omicron/issues/1705

The first iteration of Affinity/Anti-Affinity groups only uses a membership type of "instance UUID".

This allows clients to make individual instances affine or anti-affine from one another, but it isn't yet possible to describe "I want this group of instances to be anti-affine from one another".

This feature was described in RFD 522:

An Anti-Affinity Group is a collection of Interfaces or Affinity Groups that are intended to be deployed in different fault domains

This issue tracks that feature. This should be possible by adding a new anti-affinity member type.

Note that this feature is asymmetric with respect to affinity groups. There is currently no intention to allow "affinity groups consisting of anti-affinity groups" (since that construction wouldn't make much sense).

Start by reading RFD 522's anti-affinity-group section and the related issue #1705 to understand the existing membership model. Trace the current affinity and anti-affinity group API entry points and tests, then identify the changes needed for a new anti-affinity member type. Done means anti-affinity groups can contain affinity groups while the unsupported reverse relationship remains disallowed.