Allow opening additional ports on the driver

[mccheah]

A use case @ash211 and I are building requires exposing additional ports on the driver pod. It should be straightforward enough to support either <name>=<value> ports or just a comma-separated list of numbers. I'm inclined to provide just the list of numbers to keep things simple.

We may not have to go to the extent of exposing these ports on the service we create for the Spark UI just yet - the user can currently provide their own custom label that locates their pod and create a service overlay on top of the opened ports via this configuration.

[mccheah]

We should be careful to minimize the number of additions of these kinds of features - #38 is the right catch-all if the feature set grows too large.

[foxish]

How common a use case is it to need additional ports exposed? That should be the deciding factor for whether we want to support it as an option, or in the custom pod yamls. @ssuchter thoughts?

[ash211]

This is very common with our Spark jobs (and the path forward for all new Spark jobs we write), though I can't say how common it is elsewhere.

[mccheah]

We didn't end up needing this - can revisit later if it would be convenient in general.