This is a transfer of work from hashicorp/terraform#15167.

This adds the aws_security_group_attachment resource, allowing one to
attach security groups to ENIs outside of an aws_instance or
aws_network_interface resource.

Use cases for this would include more granular management of security
groups, or attachment of security groups to instances that are managed
out-of-band from Terraform.

Renamed as pre review comments in hashicorp#860. This should help differentiate
it between the other kinds of security groups available in the AWS
provider.

This attribute was set to optional back when this resource allowed
either an instance or network interface specified. Now that this is no
longer the case, there's no reason to keep it this way.

Make the test configs a bit easier to understand. Each case (via
resource or data source) now has its own config, but we still
parameterize on enabling/disabling the security group resource for the
removal check.

The resource was actually racing when there was multiple attachments
trying to work with the same network interface. This is fixed now with
locks added in create and delete.

The added test checks the race in a couple of steps, switching up the
resource names on the second run for the security groups and security
group attachments to get a good mix of creation and deletion events to
really test the effectiveness of the serialization.

Also a small cosmetic re-refactoring of test names and configuration
generation functions.

Simplified the interface check function so that the test case directly
takes the attribute that we are deriving the interface ID from, rather
than taking a bool. This actually uncovered the fact my attribute logic
was reversed (the bool logic was giving primary_network_interface_id for
a false value passed to checkPrimaryInterfaceAttr instead of a true
value, and this error was propagated to the test cases). So this is
fixed now as well.

Race check needed simplifying as well, in addition to being reduced from
two steps to one.

Reason for the latter is once security groups were modified so that the
were operating off the same set of groups in both steps (so step1 ->
step2), it was discovered that there was no way we could reasonably
expect the deletion/creation order would never favour a situation where
the new SG attachment would be ordered after the old SG attachment was
removed (as both step1 destroys and step2 creations would be happening
at the same level in the graph and without any dependencies).

Removed a bunch of the single-use functions, which has moved most logic
to the main CRUD functions. The old functions served a purpose when this
resource was designed to support both instance IDs and network interface
IDs, but just adds more cruft now that only network interface IDs are
supported.

Also moved all the messages to the DEBUG level as TF_LOG=info does not
mean anything at a provider level, currently.