Compose TemplateURLs from parameters

This composes the formerly hard coded nested stack `TemplateURL` properties from parameters. The current pattern resembles the one in place so far, e.g.:

```json
"https://s3.amazonaws.com/ci-elasticsearch-development-flow/aws-cloudformation/master/secgrp-single-default.template"
```
becomes

```json
"Fn::Join": [
"/",
[
	"https://s3.amazonaws.com",
	{ "Ref": "S3BucketName" },
	{ "Ref": "S3BucketPrefix" },
	{ "Ref": "RepositoryBranch" },
	"secgrp-single-default.template"
]
]
```

### Rationale

The slight template noise introduced like so aside, this makes sense to me given the following assumptions:

* `S3BucketName` - a user would like to use an arbitrary bucket
* `S3BucketPrefix` - a bucket might be used for various projects/contexts, distinguished by prefix
* `RepositoryBranch` - a user mirrors the branches of an existing GitHub repository to S3 (we should automate that, either via Jenkins or maybe even a self contained GitHub commit hook based PaaS solution)
 * `RepositoryBranch` is also used for bootstrapping already, so tying these seems reasonable

#### Questions

* :question: Should the template name also be a parameter?
 * Given the branch approach outlined above probably not, but it would make sense if users would upload templates to a S3 bucket manually rather than mirroring their GitHub repo, which is also a reasonable approach.
* :question: Should the S3 base URL also be a parameter?
 * I'd probably prefer that (alternatively it could be composed too, see below), but we can skip it for simplification here right now
 * Background is the (odd) CloudFormation API requirement of having the `TemplateURL` on S3 in the very region you create a stack from (this requirement has fortunately been dropped from the nested stack `TemplateURL`)
 * This issue is further complicated by the utterly annoying legacy [Amazon Simple Storage Service (S3) endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region) inconsistency, where they have named the `us-east-1` constrained endpoint `s3-external-1.amazonaws.com` rather than just `s3-us-east-1.amazonaws.com`, with the latter allowing easy composition, whereas the former requires a map lookup for a cross region solution