Favor static deployment artefacts

[gberche-orange]

The dynamic deployment artifacts currently proposed in deploy.sh makes it hard to leverage 3rd deployment tools such as https://github.com/mevansam/terraform-provider-cf using syntax close to https://github.com/gberche-orange/terraform-cloudfoundry-demo/blob/6adc711ba9de5277db75c60ff9909ec295b76629/provider_cloudfoundry.tf#L57-L69

cf-services-bench/deploy_on_cf.sh

Lines 21 to 55 in 24752e9

	echo 'Setting Python version'
	cat << EOF > app/runtime.txt
	python-3.6.4
	EOF
	echo $SEPARATOR
	echo 'Generating API deployment files'
	cat << EOF > app/.cfignore
	bin/
	lib/*.lua
	lib/*.so.*
	lib/*.so
	*pycache*
	EOF
	cat << EOF > manifest.yml
	name: ${APP_NAME}_api
	memory: $CF_INSTANCE_MEMORY
	instances: $CF_INSTANCES
	buildpack: $CF_BUILDPACK
	path: app/
	env:
	SCENARIO: $APP_SCENARIO
	services:
	- $APP_REDIS_STORAGE
	$(for service in $(echo $APP_SERVICES_TO_BENCH);do echo " - $service";done)
	EOF
	cat << EOF > app/Procfile
	web: python -m cf_services_bench
	EOF
	echo $SEPARATOR
	echo 'Deploying API'
	cf push

Suggesting to instead:

• use static deployment artifacts (manifest.yml .cfignore) possibly a single manifest file specifying api and work apps (with multi-apps CF CLI manifest suport)
• in a 1st step, leave the static manifest with sensible defaults (APP_SCENARIO, redis service name)
• in a 2nd step consider, proposing variable substitution for easily overring defaults https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution