Fix #1736: Add Bazel Linter to the project

[anandwana001]

Explanation

Fix #1736

This is the first part where we want to add linter for bazel.

How to test

1. Run command brew install buildifier on your root - this will install the buildifier
2. Go to oppia-android project root
3. You can either run command for single files or all at once

 buildifier --lint=warn --mode=check --warnings=all oppia_android_test.bzl
 buildifier --lint=warn --mode=check --warnings=all BUILD.bazel
 buildifier --lint=warn --mode=check --warnings=all WORKSPACE
or 
 buildifier --lint=warn --mode=check --warnings=all oppia_android_test.bzl BUILD.bazel WORKSPACE

4. If you want to see what auto-fix of this linter do

 buildifier --lint=fix --warnings=all oppia_android_test.bzl
 buildifier --lint=fix --warnings=all BUILD.bazel
 buildifier --lint=fix --warnings=all WORKSPACE
or 
 buildifier --lint=warn --mode=check --warnings=all oppia_android_test.bzl BUILD.bazel WORKSPACE

There are currently two types of issue which auto-fix cannot fix

1. out-of-order-load - lexicographical order, mentioned in the comments below
2. unsorted-dict-items -

How to review

Until now in this PR, I had fixed and added only root bazel files in checks. Before moving forward with the bazel files in modules, we need to clarify a few points which are a bit different way a linter fix the issues.

Now

./buildifier --lint=warn --mode=check --warnings=all BUILD.bazel WORKSPACE oppia_android_test.bzl

After First Review, I will add all bazel files to check

./buildifier --lint=warn --mode=check --warnings=all -r app data domain model testing utility BUILD.bazel WORKSPACE oppia_android_test.bzl

Checklist

• The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
• The PR follows the style guide.
• The PR does not contain any unnecessary auto-generated code from Android Studio.
• The PR is made from a branch that's not called "develop".
• The PR is made from a branch that is up-to-date with "develop".
• The PR's branch is based on "develop" and not on any other branch.
• The PR is assigned to an appropriate reviewer in both the Assignees and the Reviewers sections.

[BenHenning]

Thanks @anandwana001! This looks like a great start. Left some comments.

[anandwana001]

As of now, I am trying to remove the package(default_visibility) and getting an error where the utility module has to access "//app:crashlytics", and "//app:crashlytics_deps". As "//app:crashlytics_deps", is an android_library, I can set visibility to public but cannot provide visibility to "//app:crashlytics",. This can be resolved by package(default_visibility=["//utility:__subpackages__"]).
Another error comes is root level BUILD not able to access app:manifest which is solved by using export_files.

[anandwana001]

As of now, I am trying to remove the package(default_visibility) and getting an error where the utility module has to access "//app:crashlytics", and "//app:crashlytics_deps". As "//app:crashlytics_deps", is an android_library, I can set visibility to public but cannot provide visibility to "//app:crashlytics",. This can be resolved by package(default_visibility=["//utility:__subpackages__"]).
Another error comes is root level BUILD not able to access app:manifest which is solved by using export_files.

Not solved, another error with other manifest files.

[vinitamurthi]

This expects the buildifier path to be the current path right? When we introduce pre-push hooks, that may not be the case so let's add an install path variable and prefix this call with that

[aggarwalpulkit596]

LGTM

[anandwana001]

Closing this PR and continuing the work in different PR and will follow the reviews there, as there is a bunch of conflicts hereafter changing the package naming.