Source Code Format Checks

[DellaBitta]

This change includes some tools to keep a consistent format of the repository's source files, including:

• a Checks workflow which errors if any of a branch's changed files require formatting. We can extend this workflow with copyright header checks in the future and the pre-existing Check PR Labels has been folded into it.
• updates to install_prereqs_desktop.py to ensure that clang-format is installed.
• updates to scripts/format_code.py to reduce logging in non-verbose mode.
• a pre-commit githook. Note that the githook has to be installed manually by copying it from scripts/git/hooks/pre-commit to .git/hooks/pre-commit
• an update to our Contribution guidelines with formatting instructions.

[jonsimantov]

Suggestion (possibly for a new PR) - add a label to autoformat a PR and push the changes in another commit, in case the developer doesn't want to run the formatter locally.

[jonsimantov]

Wonder if we should merge Check PR Labels into this, to reduce the number of workflows running. WDYT?

[DellaBitta]

Sure. I can do that tomorrow morning.

[DellaBitta]

Done.

[DellaBitta]

Suggestion (possibly for a new PR) - add a label to autoformat a PR and push the changes in another commit, in case the developer doesn't want to run the formatter locally.

Just a heads up that the PR that we've been reviewing from a third party user submission has had issues with our itest labels.
The issues stem from the fact that all of the workflows are being run from the user's github account, not ours, and they don't have write permissions on firebase repos. This prevents some of the label steps from completing successfully -- - maybe only the ones which post comments..?

I don't know if that applies at all to what you're suggesting, but I think that we need to retool the label control & flow that we already have.

[vimanyu]

minor python readability comments.

[jonsimantov]

Suggestion (possibly for a new PR) - add a label to autoformat a PR and push the changes in another commit, in case the developer doesn't want to run the formatter locally.
Just a heads up that the PR that we've been reviewing from a third party user submission has had issues with our itest labels.

Yeah, I'm aware of those issues. I still feel that this is worth doing for our internal development. Also, I have been thinking about switching over to using firebase-workflow-trigger's token to make the changes, where we were previously using the github-action default token to do. Do you know if the itest runs from forked repos have access to our repo's secrets?

[vimanyu]

LGTM!