Add PostgreSQLServerConfiguration managed resource

[ulucinar]

Description of your changes

Support for configuring PostgreSQLServer parameters. If the configuration has been applied successfully, the PostgreSQLServerConfiguration MR will have the Ready condition in its status.

Setting the external-name annotation
When you run az postgres server configuration list to list available configurations for a psql instance, you will observe a JSON array of configuration objects similar to the following:

{
    "dataType": "Boolean",
    "defaultValue": "on",
    "description": "Enable input of NULL elements in arrays.",
    "id": "/subscriptions/.../resourceGroups/alper/providers/Microsoft.DBforPostgreSQL/servers/example-psql/configurations/array_nulls",
    "name": "array_nulls",
    "type": "Microsoft.DBforPostgreSQL/servers/configurations",
    "value": "on"
    ...
  }

My observation is that for a psql (server) configuration that has not been manipulated previously, the postgresql.ConfigurationsClient.Get will report a 404 and for the MR, postgresqlserverconfiguration/external.Create will be called accordingly. However, if it has previously been manipulated, and even if it's set to its default value and its source is reset to system-default, I have observed that postgresql.ConfigurationsClient.Get returns the configuration object and postgresqlserverconfiguration/external.Create is thus not called. For this reason, we also set the external-name during postgresqlserverconfiguration/external.Observe if it's not already set. The external name takes the following form:
/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.DBforPostgreSQL/servers/<psql server name>/configurations/<configuration name>

Deletion Semantics
postgresql.ConfigurationsClient does not have a delete method, probably because these configuration objects somewhat always exist for a psql instance (their sources being set to system-managed), but as explained above, this behavior is not consistent. While deciding on what to do when a PostgreSQLServerConfiguration MR is deleted, I took a look at how Terraform's azurerm_postgresql_configuration resource behaves, and as revealed by an az postgres server configuration show, it resets the configuration value to the default value but does not reset its source. I've chosen to implement a similar behavior of resetting to the default value but also its source is reset to system-managed. As explained above, my observation is that the configuration object still exists in ARM and thus I had to observe the deletionTimestamp on the MR together with its source being system-managed and its value being equal to its defaultValue for removing the finalizer on the MR.

Fixes #281

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable test to ensure this PR is ready for review.
• Add automated test

How has this code been tested

I've manually configured an existing PostgreSQLServer instance's max_wal_senders parameter using a PostgreSQLServerConfiguration MR.

[muvaf]

Thank you @ulucinar for working on this challenging resource! I have a few comments but it mostly looks good.

[muvaf]

It might be worth to have a code comment about why we call update.

[ulucinar]

Done.

[muvaf]

Thank you @ulucinar !

[ulucinar]

Thanks @muvaf for the support.