Remove cf_service_binding non implemented resource doc

[gberche-orange]

Removal of cf_service_binding resource which is not implemented and whose support is currently in cf_app.service_binding resource

As discussed during weekly meeting on Feb 26th implementing a cf_service_binding resource would create the following problems:

1- cf_app.service_binding resource would overlap with the cf_service_binding resource.

As a result, two TF resources are potentially competing to manage the same CF resource, leading to race conditions.

I searched for definitive guidance over such syntaxic sugar practices in resource modeling and ran so far in hashicorp/terraform#2957 (comment)

we separated out aws_volume_attachment as its own resource which is a strategy we've consistently taken to declaratively model links between two resources (aws_instance and aws_ebs_volume) in this case.

hashicorp/terraform#2081 (comment)

(1) First prefer explicit, verbose, and flexible modelling
(2) Then layer on syntactic sugar and convenience features to make configs easier to read and write

There seems to have examples of such overlapping modeling in the AWS reference provider, e.g. https://www.terraform.io/docs/providers/aws/r/elb_attachment.html or https://www.terraform.io/docs/providers/aws/r/autoscaling_attachment.html and hint users with:

NOTE on ELB Instances and ELB Attachments: Terraform currently provides both a standalone ELB Attachment resource (describing an instance attached to an ELB), and an Elastic Load Balancer resource with instances defined in-line. At this time you cannot use an ELB with in-line instances in conjunction with an ELB Attachment resource. Doing so will cause a conflict and will overwrite attachments.

We would therefore have to warn users about conflict between the two syntaxes.

2- Lack of orchestration between cf_service_binding and cf_app

The cf_service_binding resource can not be created before the app, and an app can not have an explicit depends_on to the service binding in order to avoid a restaging.

This comes down to the desired app state and orchestration.

Similar work in progress on AWS instance
hashicorp/terraform-provider-aws#569

This could for instance require the cf_service_binding to restage an app upon modification of the cf_service_binding (which may trigger race condition with the independent update of the cf_app resource)

3- Duplicated code and its maintenance.

Duplicated code implies work and feature mismatch e.g. #31

The following upcoming OSB API/ CF API changes might increase the maintenance cost of the overlapping modeling, and duplicated code between cf_app.service_binding and cf_service_binding

• async service bindings Support async binding operations openservicebrokerapi/servicebroker#137
• service binding updates Support update on Bindings openservicebrokerapi/servicebroker#123