Add --pre-build-helper flag to run scripts before package build

[NicholasBHubbard]

This PR implements a new feature to fpm that I refer to as "pre-build helpers". This adds a flag to fpm called "--pre-build-helper", that lets you register a program/script to be run just before a package is actually built, when the package metadata file (such as the .spec or control file) has been generated by fpm. This flag can be specified multiple times to run multiple scripts.

All pre-build helper scripts are run with the following environment variables set:

FPM_STAGING_PATH    - Absolute path to staged package contents
FPM_BUILD_PATH      - Absolute path to build artifacts (specs, control files)
FPM_OUTPUT_TYPE     - Package type (e.g. "rpm", "deb")
FPM_PACKAGE_NAME    - Package name
FPM_PACKAGE_VERSION - Package version

Myself and @wbraswell want to do "strange" things to modify our package metadata files, that really don't fit nicely into the architecture (and sanity) of fpm. Instead of trying to add our own weird flags to do things only we want to do, we came up with the idea to add this generic concept of a pre-build helper, which may be useful to others. We will personally write our strange code as custom scripts that are invoked as pre-build helpers.

I added tests for this new feature for every output-capable package type that already had a test script (I did not create new test scripts for the package types that don't have one). These tests are strong since they test not only that the pre-build helpers are run, but that they are run at the correct time when the package metadata file exists.

It is important to note that I had to go in to every package output method, and insert a call to run_pre_build_helpers in the correct place such that they are invoked after the metadata files have been created. It would be nice if we only had to make this call once (from command.rb's execute function). However fpm's architecture for the output method is not fine-grained enough for this to be possible. This actually reminds me a lot of our previous work on adding source-based packages (#1972, #1967, #1954), where we tried to split the functionality of input and output into more functions to allow more fine-grained control over the package build process.

Let me know your thoughts and how things look!

[wbraswell]

@jordansissel
We think this may be one of our last big PRs before we are finally able to move forward with all our Perl packaging plans. As always, I have carefully reviewed every step of the design and implementation with @NicholasBHubbard before we ever submitted it for your approval. Thank you for your timely response to this PR! :-)

[wbraswell]

Howdy @jordansissel , I hope you are doing well sir! :-)

This PR #2145 and our other open PR #2146 seem to be the last two big hurdles we need to overcome in order to move forward with our current tasks and goals. While they are not related from FPM's point of view, they are related from our Perl point of view and we believe they are both as non-intrusive to FPM as possible.

Can you please take a few minutes now to review and approve these two PRs?

[jordansissel]

I briefly read the PR and this looks fairly straightforward. I want to try it to get you some better feedback shortly; I’m busy with some family medical stuff these past weeks and haven’t had the headspace to move this forward. Hopefully soon!

Thanks for working on this!

[wbraswell]

@jordansissel
Okay sounds good, thank you sir!