Add default workflow for Gradle's dependency-submission action

[BraisGabin]

https://github.com/gradle/actions/blob/v3.0.0/dependency-submission/README.md#general-usage

Also from the README:

The gradle/actions/dependency-submission action provides the simplest (and recommended) way to generate a dependency graph for your project. This action will attempt to detect all dependencies used by your build without building and testing the project itself.

The dependency graph snapshot is generated via integration with the GitHub Dependency Graph Gradle Plugin, and submitted to your repository via the GitHub Dependency Submission API. The generated snapshot files can be submitted in the same job, or saved for submission in a subsequent job.

The generated dependency graph includes all of the dependencies in your build, and is used by GitHub to generate Dependabot Alerts for vulnerable dependencies, as well as to populate the Dependency Graph insights view.

(This is basically a cherry-pick from this PR: detekt/detekt#6933)

[BraisGabin]

It's scary the list of dependencies that this simple project has: https://github.com/detekt/sarif4k/network/dependencies

[TWiStErRob]

I think for this to be as useful as #90 was, an admin (@BraisGabin @cortinico @chao2zhang?) has to press a button somewhere here:

because this page is empty:
https://github.com/detekt/sarif4k/security/dependabot

Compare with detekt.

[BraisGabin]

Done, now it isn't empty.

[TWiStErRob]

"Great"... thanks.

[BraisGabin]

And now it's empty. I must say that handle this kind of vulnerabilities is a PITA. It's completely different a vulnerability on gradle than a vulnerability that we introduce on the artifact that we release.

[TWiStErRob]

It doesn't mean we're providing vulnerable code, it means WE (our CI and our local machines) ARE vulnerable. We actually use XML because Gradle parses POM files. There's nothing we can do about this though other than report it to Gradle and keep it up to date.