Reduce repo complexity and consolidate specs

[diamonwiggins]

Currently, we have many different specs and it's not clear which you should provide when a user needs to generate a support bundles. We should consolidate any specs that don't need to be separate, create a directory structure to further organize any one-of specs, and maintain a default.yaml or all.yaml that is an aggregate of all specs in the respective host and in-cluster directories. New directory structure could look similiar to:

host/
  networking/
  resource-contention/
  default.yaml
in-cluster/
  kurl/
  other/
  default.yaml

• Remove any unneeded specs
• Consolidate any specs that don't need to be separate into default.yaml
• Maintain a Makefile which has a make generate-cluster-specs/make generate-host-specs or something similar that's required to be run before a PR can be merged
• Update the DNS address for https://support-bundle.replicated.com to point to the raw result of in-cluster/default.yaml

[banjoh]

I think we can serve both in-cluster and host default specs using https://support-bundle.replicated.com?spec=in-cluster or https://support-bundle.replicated.com/in-cluster. I prefer the latter cause of ease of caching

[xavpaice]

Currently https://support-bundle.replicated.com redirects to https://raw.githubusercontent.com/replicatedhq/troubleshoot/master/examples/support-bundle/sample-supportbundle.yaml which is a placeholder example with little use to anyone other than to help write a real spec.

Outstanding for this issue:

• update https://support-bundle.replicated.com to point at a useful spec (or add to the URL for different specs) (Set https://support-bundle.replicated.com to point to useful specs #75)
• Define what we want in a Makefile and add it (Create a Makefile to make specs #74 )

I've created separate issues for the remaining items since they do appear to be separate to the main event for this issue, and will close this one now.