Add note about registering Closure/Soy Custom Functions.

closes #153

src/main/docs/guide/views/templates/soy/soyusage.adoc

@@ -13,6 +13,8 @@ A naive implementation of api:views.soy.SoyFileSetProvider[] could look like:
 
 snippet::io.micronaut.docs.soy.CustomSoyFileSetProvider[tags="clazz"]
 
+NOTE: Soy allows users to write custom functions that templates can call, as described by their docs for https://github.com/google/closure-templates/blob/master/documentation/dev/plugins.md[Creating a Plugin]. If you have one or more implementations of https://github.com/google/closure-templates/blob/master/java/src/com/google/template/soy/plugin/restricted/SoySourceFunction.java[SoySourceFunction], you can register them in the `SoyFileSetProvider.provideSoyFileSet()` method using SoyFileSet builder's `addSourceFunction(SoySourceFunction)` or `addSourceFunction(Iterable<? extends SoySourceFunction>)` methods.
+
 The return value of the following Controller is converted to Soy template context parameters, and passed to the `@View`-annotation-bound template.
 
 snippet::io.micronaut.docs.soy.SoyController[tags="clazz"]
@@ -24,4 +26,4 @@ Both server-side Soy rendering layers are supported in Micronaut Views Soy:
 * `SoySauceViewsRenderer`: This renderer uses templates pre-compiled to Java bytecode, generally AOT, with
 `SoyToJbcSrcCompiler`. If compiled templates can't be located by the `SoyFileSetProvider`, templates are pre-compiled
 into bytecode at server startup. This can be impactful on startup-time, so, if that's an important metric for your
-app, pre-compile your templates using the AOT bytecode compiler.
+app, pre-compile your templates using the AOT bytecode compiler.