Fix redundant ifs and selects in generated build files

Particularly in the Bazel rules, having select statements makes
it hard for clients to use the rules. For example,
src/tint/lang/glsl/writer/printer/BUILD.bazel had a conditional
dependency on src/tint/lang/glsl/writer/common which means any client
building tint needed to make sure those args were set also, which
is awkward, especially in big monorepos.

When I looked closer, I noticed the GN and CMake rules had redundant
if statements here:
    if (tint_build_glsl_writer) {
        deps = [...]
        if (tint_build_glsl_writer) {
            deps += [...]
        }
    }

and could be condensed. After fixing this, I noticed a few
Bazel targets had empty strings sneak into deps, which causes problems.

This was from proto rules which weren't fully implemented,
so this implements the generation of those proto targets.

Suggested review order:
 - tools/src/cmd/gen/build/target.go which still makes
   UnconditionalSourceFiles return only those which have no conditions,
   and adds UnconditionalInternalDependencies to return things
   which are conditional but covered by the targets conditions,
   and UnconditionalExternalDependencies which is the same but
   for things outside of Tint.
 - tools/src/cmd/gen/build/BUILD.gn.tmpl and tools/src/cmd/gen/build/BUILD.cmake.tmpl
   which only add conditions if they aren't already covered by
   the targets conditions.
 - tools/src/cmd/gen/build/BUILD.bazel.tmpl which adds support for
   protos and avoids adding select statements for conditions
   covered by the target.
 - Everything else is autogenerated. Looking at src/tint/lang/glsl/writer/printer/BUILD.bazel
   and src/tint/cmd/fuzz/ir/as/BUILD.bazel and
   src/tint/utils/protos/ir_fuzz/BUILD.bazel are good for
   spot-checking.

Change-Id: Ibd24495b34d2ea648104f9f183cfa3d1fdddecb2
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/308615
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Kaylee Lubick <kjlubick@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Reviewed-by: James Price <jrprice@google.com>