Stop hardcoding properties in newConvertToARMFunctionBuilder (#3685)

This fixes #3549.

This uses a property tag for a few reasons:
  1. Some types are flattened and other approaches are easily
     lost when flattening occurs. Putting the tag onto the property
     preserves it even through flattening.
  2. In many ways this behavior is like an augmented `json:omitempty`,
     so it (IMO) makes sense to have a tag just like for JSON. It makes
     it clearer when looking at the Go object that the serialization behavior
     of these fields is special.

This also fixes an issue with the configuration where hierarchical
configurations didn't propagate the checks for usage.