feat: allow to set default ingressclass

[Jasstkn]

Description

allows to set default ingress class. useful in case of multiple nginx ingress controllers.
fixes #983

Motivation and Context

• I have raised an issue to propose this change, which has been given a label of design/approved by a maintainer (required)

How Has This Been Tested?

If updating or adding a new CLI to arkade get, run:

$ ./arkade install nginx-ingress
...

$ k describe ingressclass nginx
Name:         nginx
Labels:       app.kubernetes.io/component=controller
              app.kubernetes.io/instance=ingress-nginx
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=ingress-nginx
              app.kubernetes.io/part-of=ingress-nginx
              app.kubernetes.io/version=1.9.3
              helm.sh/chart=ingress-nginx-4.8.2
Annotations:  ingressclass.kubernetes.io/is-default-class: true
              meta.helm.sh/release-name: ingress-nginx
              meta.helm.sh/release-namespace: default
Controller:   k8s.io/ingress-nginx
Events:       <none>

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Documentation

• I have updated the list of tools in README.md if (required) with ./arkade get --format markdown
• I have updated the list of apps in README.md if (required) with ./arkade install --help

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s

• I have tested this on arm, or have added code to prevent deployment

[Shikachuu]

If we set this as default isn't this a backward incompatible change?

I think it would be better with default false.

[Jasstkn]

but what's the point for it being false? i thought that idea is to preconfigure application to be up&fully functional for development/testing purposes.

[Shikachuu]

To be clear, your approach makes more sense, if we have no promise for backward compatibility (which afaik we doesn't) you are right, it is better this way then.

[alexellis]

Thanks both