RFC: Add "modern" version of closure_template_library

## Current situation

`closure_template_{java,js}_library` has been part of `rules_closure` for some time.
Since its addition in 2016(?), a lot has changed, both in `rules_closure` and `Bazel`, and I think it's time to create something new. Something that looks and feels more like other "modern" `Bazel`-rules.

The current versions of `closure_template_{java,js}_library` are implemented as thin (independent) wrappers around `genrule`. This means that adding dependencies to or removing them from templates requires changing multiple targets, which is rather error-prone. Also, using closure templates from a new language (e.g. from Java if you only used them in JS) requires adding targets for all transitive dependencies.

```python
closure_template_java_library(
name = "a_java_soy",
srcs = [
"a.soy",
],
)

closure_template_js_library(
name = "a_js_soy",
srcs = [
"a.soy",
],
)

closure_template_java_library(
name = "b_java_soy",
srcs = [
"b.soy",
],
deps = [
":a_java_soy",
],
)

closure_template_js_library(
name = "b_js_soy",
srcs = [
"b.soy",
],
deps = [
":a_js_soy",
],
)
```

## New rule

The style of the new rules is inspired by `proto_library`. Instead of having per-language targets, we will create a dedicated `closure_template_library` rule that defines the dependencies between individual templates, and multiple `closure_template_{language}_library`-rules that generate language bindings for the templates.

```python
closure_template_library(
name = "a_soy",
srcs = [
"a.soy",
],
)

closure_template_library(
name = "a_soy",
srcs = [
"b.soy",
],
deps = [
":a_soy",
],
)

closure_template_java_library(
name = "b_java_soy",
deps = [
":b_soy",
],
)

closure_template_js_library(
name = "b_js_soy",
deps = [
":b_soy",
],
)
```

Internally, the language rules will use [aspects](https://docs.bazel.build/versions/master/skylark/aspects.html) to generate the language bindings for transitive dependencies.

Other design goals are:
1. figure out how integration with `closure_proto_library` should work (e.g. #314, #388), and
2. integrate the template generation into `ClosureWorker` (it currently isn't).

Review the existing closure_template_java_library and closure_template_js_library wrappers around genrule, then examine how ClosureWorker currently handles template generation. Read the linked aspects documentation and investigate the integration questions raised in issues #314 and #388. Done means agreeing on the rule design and resolving the closure_proto_library and ClosureWorker integration goals.

Written by the indexing model from the issue text.