Don't destroy and recreate subnets when their availability zone changes in the terraform config

[kaii-zen]

A subnet's availability zone can change in the terraform config in a couple of scenarios I can think of:

1. Updating Bitte on an old deployment that was not properly spread across availability zones.
2. (hypothetical) upstream changes to amazon's availability-zone/instance-type support matrix cause the terraform config logic to come up with different subnet->availability zone assignments.

In scenario 1 we may want to follow through with the change set to spread our instances across azs as per best practices, while in scenario 2 it is probably not worth the trouble.

Separating this from #154 so that we can decide on it in isolation.

[johnalotoski]

Confirming this does suppress all AZ re-arrangement changes for the cores.
Is there a similar change for clients to be done also?
Client plan still shows a large diff of AZ re-arrangement destruction.