docs: clarify compound extension signature naming for bools (#545)

#537 clarified that compound extension signatures are now required.
I noticed that the table specifying how to type those signatures didn't 
include booleans -- I _think_ it's probably `bool` but either way it 
should be included.

Also in this PR, a quick indentation fix so that the `Note:` admonitions
render correctly (there needs to be blank line and then an indented
block)

site/docs/extensions/index.md

@@ -33,9 +33,9 @@ A YAML file may contain one or more functions by the same name. The key used in
 
 Rather than using a full data type representation, the input argument types (`short_arg_type`) are mapped to single-level short name. The mappings are listed in the table below.
 
-!!! note
+!!! note 
 
-Every compound function signature must be unique.  If two function implementations in a YAML file would generate the same compound function signature, then the YAML file is invalid and behavior is undefined.
+    Every compound function signature must be unique.  If two function implementations in a YAML file would generate the same compound function signature, then the YAML file is invalid and behavior is undefined.
 
 | Argument Type              | Signature Name |
 | -------------------------- | -------------- |
@@ -48,6 +48,7 @@ Every compound function signature must be unique.  If two function implementatio
 | fp64                       | fp64           |
 | string                     | str            |
 | binary                     | vbin           |
+| boolean                    | bool           |
 | timestamp                  | ts             |
 | timestamp_tz               | tstz           |
 | date                       | date           |

site/docs/serialization/binary_serialization.md

@@ -43,10 +43,12 @@ Once the YAML file URI anchor is defined, the anchor will be referenced by zero
     ```
 
 !!! note
-  Anchors only have meaning within a single plan and exist simply to reduce plan size. They are not some form of global identifier. Different plans may use different anchors for the same specific functions, types, type variations, etc.
+
+    Anchors only have meaning within a single plan and exist simply to reduce plan size. They are not some form of global identifier. Different plans may use different anchors for the same specific functions, types, type variations, etc.
 
 !!! note
-  It is valid for a plan to include `SimpleExtensionURI`s and/or `SimpleExtensionDeclaration`s that are not referenced directly.
+
+    It is valid for a plan to include `SimpleExtensionURI`s and/or `SimpleExtensionDeclaration`s that are not referenced directly.