Ensure all relevant 'create' input fields are using pointers.

[Integralist]

NOTE: To review this PR I would recommend looking at each individual commit rather than the "Files changed" view.

---

To avoid issues where a user wants to set a zero value on a create input field (and to avoid the API potentially setting an unwanted default value) we will convert all relevant fields to pointers.

The intention is that if the user doesn't pass a pointer for one of these fields, then the data won't be marshalled and will be omitted from the request to the API. If the user sends a zero value for the field, then because it will have to be wrapped in a pointer, it means the zero value for the given field type will be sent in the request to the API.

At that point it's up to the API to either respect that zero value or not, and in some cases we know the API actually ignores the zero value and will set a default. regardless.

Additional work

I've ensured that integers use int rather than uint following the Golang guidance...

When you need an integer value you should use int unless you have a specific reason to use a sized or unsigned integer type.

...although we know some fields are always going to be positive numbers, using int is more consistent and more flexible (if the API ever needed to change), as those types of changes require tedious updates to the Fastly CLI and Fastly Terraform provider.

Other comments

Not all create operations are going to have all fields converted to pointers.

If we consider the 'token' creation endpoint (which is fastly.CreateToken()), there is no point in making a field such as Services a pointer because omitting that field will cause the API to set the token to have access to all services, and if that is undesired behaviour the user would set some form of value. Therefore, trying to allow setting of an empty value makes no sense because you would never want to create a token that didn't have access to at least a single service.

JSON API endpoints have mostly been left untouched as their semantics are a little less clear and due to complexity in their setup (e.g. TLS and WAF products) I'm not looking to mess around with those at this point in time.