feat: Add service user and legacy service user resources

[sfc-gh-asawicki]

Introduce snowflake_service_user and snowflake_legacy_service_user resources:

• Add new resources (almost the same schema and the same limitations as snowflake_user resource - read below)
• Adjust datasource and add type to the describe_output
• Adjust SDK: handling types
• Add SDK integration tests to validate and document the Snowflake behavior of handling user types (create, alter set, alter unset, and parameters)
• Fix TestAcc_User_issue2970 test
• Add migration guide
• Generate models and assertions for the new resources
• Fix sweepers

References: #2951

Implementation considerations

Users of different types differ in Snowflake just slightly - a few fields are restricted from SERVICE and LEGACY_SERVICE type users. We decided to split Snowflake resources into multiple resources on our route to V1, to simplify the logic and usage (in this case, not to handle the type changes which are followed by attributes being hidden/revealed). That led to three choices for the implementation, to reuse the existing resource:

• copy-paste snowflake_user resource
• parameterized handling methods of snowflake_user resource with the user type
• enrich the helper methods with the knowledge of the schema (i.e. to change the logic of setting a field to always check first if the attribute exists in the given schema)

Ultimately, the second option was picked for the current implementation. More details of pros and cons of each solution are presented in points below.

copy-paste

Pros:

• Fastest implementation
• We plan to ultimately generate the resources, so at the end the implementation would be close to duplicated resources

Cons:

• Need to alter the logic in three different places
• Separate implementation of resources would require separate complete set of tests

parameterized handling methods

Pros:

• user object handled in "one" place
• implementation reused, so only smoke acceptance tests are justified

Cons:

• more complex logic in user resource, spread over multiple handling methods

enrich the helper methods

Pros:

• user resource implementation could stay the same in helper methods (because the checks would be delegated to helper methods)
• solution that can be reused in more resources
• only smoke tests would be justified

Cons:

• SDKv2 does not allow to fetch the schema in context of helper methods without exposing unexported fields
• "unsafe" solution potentially used in the majority of resources (because helper methods should be reused more and more)

[github-actions]

Integration tests failure for c7aca444c4a3e3bae5ce978dd6b5ad38c5150a97

[github-actions]

Integration tests failure for 7c3737b8ed747eab803c2206d424c475d704d338

[sfc-gh-jcieslak]

shouldn't we create basic and complete version of resource configurations like for other resources?

[sfc-gh-asawicki]

Added for all user types

[github-actions]

Integration tests failure for 3a1ff98589dce8fb8287453f8a746f8963307d58