Add support for SIGABRT to KillProcessRequest_Signal, allow gNOI to generate coredumps

[aredmon8551]

All currently defined signals only have an action of terminate, none generate a core. Proposing addition of SIGABRT to support core generation:
https://man7.org/linux/man-pages/man7/signal.7.html

[coveralls]

Pull Request Test Coverage Report for Build 4236638936

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 0.0%

---

Totals
Change from base Build 4236524998:	0.0%
Covered Lines:	0
Relevant Lines:	0

---

💛 - Coveralls

[hellt]

@marcushines @aredmon8551 We also need bump the service version (and regen the protos?)

[marcushines]

Please fix lint as well as generate protos

I don't know that you have to bump as this is not breaking

[hellt]

@marcushines shouldn't new functionality (like supporting a new signal) require a bump in the minor version of a semver-styled version string?

I.e. in our product documentation we aim to provide a service version which we support, i.e. 1.2.0 plus the commit hash which we used to get the protos from.
Now if a new signal is added while the version stays the same 1.2.0, someone may expect to use that signal, judging by the version match.

I think the version should be bumped 1.0.0 -> 1.1.0 to reflect the newly added backwards compatible functionality

[hellt]

@marcushines here is a suggestion set for fixing gofmt complaints. Although the question remains what protoc-gen code made it non-compliant? Looks weird

[aredmon8551]

I had to manually pull down the referenced projects in the compile.sh script to my $GOPATH because go get fails (as I believe no main.go file exists in those projects). Script ran without issues, though unsure if go install and go get should be used here.