NullPointerException using rustfmt_aspect with custom verilog_lint_test rule

Originally logged here: https://github.com/bazelbuild/bazel/issues/15753

We see the following splat:

```
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node '[]#@rules_rust//rust/private:rustfmt.bzl%rustfmt_aspect BuildConfigurationValue.Key[614a8816f292c11cb4ef63601cc72f3c9ff3ca3f749cc82148f834a38f437e65] ConfiguredTargetKey{label=//hw/projects/mlm/dv/csr/mem_wrapper/pmw:pmw_blk_ram1_lint, config=BuildConfigurationValue.Key[614a8816f292c11cb4ef63601cc72f3c9ff3ca3f749cc82148f834a38f437e65]} {}' (requested by nodes 'com.google.devtools.build.lib.skyframe.AspectKeyCreator$TopLevelAspectsKey@d4cddab9')
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:674)
at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:382)
at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at net.starlark.java.eval.Starlark.checkValid(Starlark.java:112)
at net.starlark.java.eval.Dict$Builder.put(Dict.java:434)
at com.google.devtools.build.lib.analysis.starlark.StarlarkAttributesCollection$Builder.addAttribute(StarlarkAttributesCollection.java:227)
at com.google.devtools.build.lib.analysis.starlark.StarlarkRuleContext.(StarlarkRuleContext.java:277)
at com.google.devtools.build.lib.analysis.RuleContext.initStarlarkRuleContext(RuleContext.java:1151)
at com.google.devtools.build.lib.skyframe.StarlarkAspectFactory.create(StarlarkAspectFactory.java:52)
at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createAspect(ConfiguredTargetFactory.java:536)
at com.google.devtools.build.lib.skyframe.AspectFunction.createAspect(AspectFunction.java:867)
at com.google.devtools.build.lib.skyframe.AspectFunction.compute(AspectFunction.java:464)
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:590)
... 7 more
```

when rules_rust's rustfmt_aspect is configured in bazelrc as follows:

```
build --aspects=@rules_rust//rust:defs.bzl%rustfmt_aspect
build --output_groups=+rustfmt_checks
build --@rules_rust//:rustfmt.toml=//:.rustfmt.toml
```

This happens when the aspect is combined with our internal verilog_lint_test rule and something we feed Bazel makes it unhappy (details omitted):

```starlark
_verilog_lint_test = rule(
implementation = _verilog_lint_test_impl,
test = True,
attrs = {
# ...
# ...
# ...
)
```

and:

```starlark
def _verilog_lint_test_impl(ctx):
# ...
# ...
# ...
print("test script %s" % test_script)
print("runfiles %s" % runfiles)
return [DefaultInfo(runfiles = runfiles, executable = test_script)]
```

Those two prints happen before the splat:
```
DEBUG: /home/edwin/internal/bazel/eda/verilog.bzl:527:10: test script
DEBUG: /home/edwin/internal/bazel/eda/verilog.bzl:528:10: runfiles Analyzing: target //hw/projects/mlm/dv/csr/mem_wrapper/pmw:pmw_blk_ram1_lint (133 packages loaded, 3903 targets configured)
```

I don't know enough about what Bazel expects the rule to return to know if the return value is legal.