Fix Note markup

doc/specs/vulkan/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt

@@ -29,7 +29,7 @@ same code:ANativeWindow and any attempts to connect to the same
 code:ANativeWindow through other platform mechanisms will fail.
 
 [NOTE]
-.NOTE
+.Note
 ====
 In particular, only one sname:VkSurfaceKHR can: exist at a time for a given
 window.

doc/specs/vulkan/chapters/features.txt

@@ -18,7 +18,7 @@ explicitly queried before use to ensure they are supported by the
 implementation.
 
 [NOTE]
-.Note on extensibility
+.Note
 ====
 The features and limits are reported via basic structures (that is
 slink:VkPhysicalDeviceFeatures and slink:VkPhysicalDeviceLimits), as well as

doc/specs/vulkan/chapters/resources.txt

@@ -3890,8 +3890,8 @@ A buffer or image memory barrier is not required to acquire _ownership_ when
 no queue family owns the resource - it is implicitly acquired upon first use
 within a queue.
 
-.Note
 [NOTE]
+.Note
 ====
 Images still require a <<resources-image-layouts, layout transition>> from
 ename:VK_IMAGE_LAYOUT_UNDEFINED or ename:VK_IMAGE_LAYOUT_PREINITIALIZED

doc/specs/vulkan/chapters/shaders.txt

@@ -278,8 +278,8 @@ The order that coherent writes to different locations become available is
 undefined, unless enforced by a memory barrier instruction or other memory
 dependency.
 
-.Note
 [NOTE]
+.Note
 ====
 Explicit memory dependencies must: still be used to guarantee availability
 and visibility for access via other buffers, buffer views, or image views.
@@ -295,8 +295,8 @@ write.
 Atomic operations ensure automatic availability and visibility for writes
 and reads in the same way as those to code:Coherent variables.
 
+[NOTE]
 .Note
-[[NOTE]]
 ====
 Memory accesses performed on different resource descriptors with the same
 memory backing may: not be well-defined even with the code:Coherent