Improve Builder Flag Names

[lkingland]

The --builder-image flag introduced in #923 presents possible confusion with --builder.

cmd.Flags().StringP("builder", "b", "pack", "builder to use when creating the underlying image. Currently supported builders are 'pack' and 's2i'.")
cmd.Flags().StringP("builder-image", "", "", "builder image, either an image name or a mapping name.\nSpecified value is stored in func.yaml for subsequent builds. ($FUNC_BUILDER_IMAGE)")

As is mentioned during code review, we should take the time to consider possible alternative names or a wholesale refactor of this feature.

[lance]

I suggest using --strategy and -s for the builder type, e.g. buildpack or s2i. I can even see a docker strategy being reasonable at some point in the future, to allow developers to really customize the resulting image. And use builder or builder-image for the image name. I think builder might be better because it doesn't tie us down to an image as the only reasonable type of value.

[zroubalik]

I like the proposal by @lance

[lkingland]

I think builder might be better

Agreed. If we use --strategy, there is no longer a name collision on --builder, so we can move --builder-image back to just
--builder.

[lance]

@lkingland what's your thought on this now? Given that there is now consistency between build and deploy (once #1065 lands), and the fields in func.yaml have been cleaned up. I suppose using --strategy is nice. Is it necessary? @zroubalik?

[lkingland]

I would agree that now that we are consistent, this issue may be considered closed.

The initial confusion seems to have been caused more by a mismatch between the flag names and the structure fields, and now that we have refactored a bit to support S2I via #1021, #1024, #1028, #1033 and #1065, they are now in sync and would probably cause the same confusion but in reverse if pursued

[lance]

Closing per discussion