Migrate 2017 frontend service to use 2017.civicplatform.org FQDN

[MikeTheCanuck]

The 2017 frontend service currently is hosted on two domains: civicpdx.org and 2017.civicpdx.org.

@DingoEatingFuzz and I discussed this today and agreed that we can simplify and deprecate the civicpdx.org nomenclature by hosting the 2017 frontend services instead at 2017.civicplatform.org.

This means a few changes:

• replace the civicpdx.org and 2017.civicpdx.org A records with CNAME records (so we can handle all redirection at the DNS level, while relieving our infrastructure of any legacy hard-coded association with these domains)
• update the 2017-civic-service.yaml template to only have a single Host record that uses the 2017.civicplatform.org domain instead of the two Host and Host2 records it currently binds to

Once we've completed this migration, it will be trivial to create a new frontend.yaml template that can configure both the 2017 and the 2018 (which is now becoming a 2018-and-2019) containers from a single template.

And as this is going to mean net-new DNS records, I'm going to add them to our CloudFormation stack so that we can understand how to tie our DNS into the CF orchestration.

[MikeTheCanuck]

References used to figure this out: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-route53.html#scenario-recordsetgroup-zoneapex https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html

[MikeTheCanuck]

With https://github.com/hackoregon/hackoregon-aws-infrastructure/pull/91 and https://github.com/hackoregon/hackoregon-aws-infrastructure/pull/90 we can verify that the domains are directing to their intended destinations even when migrated to Fargate.