phase_merge_jars: refactor to separate function that merges jars to o…

[gergelyfabian]

…utput

Description

Add a new function that is independent of runtime jars and the specific output.

Motivation

This is a small refactoring as an intermediate step for possible extensions for creating custom outputs. Not sure yet how to add those extensions, but such a refactoring here may be very useful.

An example how this can be changed further:

https://github.com/gergelyfabian/rules_scala/compare/refactor_phase_merge_jars...gergelyfabian:external-and-internal-deploy-jar?expand=1

[gergelyfabian]

Here is the intended usage: https://github.com/gergelyfabian/rules_scala/commit/0cd31de8bc1b6f815afb7debde76aae959f855c5

We had a usecase, that we wanted to generate fat jars with "internal" and "external" dependencies separately (to be able to package them separately for caching reasons). Wondering what route should be optimal for this. We were also considering to add custom phases from our own application (we could reuse part of this code then, I guess).

[liucijus]

@gergelyfabian do you still need or use this change?

[gergelyfabian]

Yes, we do all the time. We produce 3 jars for each scala_library we have and put them in 3 separate docker layers (i.e. we don't want external dependency jars - that change infrequently - land in the same layer as our internal deps - that change frequently).

[liucijus]

Sorry for taking so long, @gergelyfabian