Docs cleanup

docs/modules/ROOT/pages/kafka/kafka-binder/dlq-partition.adoc

@@ -1,5 +1,5 @@
 [[dlq-partition-selection]]
-== Dead-Letter Topic Partition Selection
+= Dead-Letter Topic Partition Selection
 
 By default, records are published to the Dead-Letter topic using the same partition as the original record.
 This means the Dead-Letter topic must have at least as many partitions as the original record.

docs/modules/ROOT/pages/spring-cloud-stream/binding-names.adoc

@@ -1,5 +1,5 @@
-[[binding-and-binding-names]]
-== Binding and Binding names
+[[binding-names]]
+= Binding and Binding names
 
 Binding is an abstraction that represents a bridge between sources and targets exposed by the binder and user code,
 This abstraction has a name and while we try to do our best to limit configuration required to run spring-cloud-stream applications,

docs/modules/ROOT/pages/spring-cloud-stream/explicit-binding-creation.adoc

@@ -1,5 +1,5 @@
 [[explicit-binding-creation]]
-=== Explicit binding creation
+= Explicit binding creation
 
 In the previous section we explained how bindings are created implicitly driven by the names of `Function`, `Supplier` or `Consumer` beans provided by your application.
 However, there are times when you may need to create binding explicitly where bindings are not tied to any function. This is typically done to

docs/modules/ROOT/pages/spring-cloud-stream/functional-binding-names.adoc

@@ -1,5 +1,5 @@
 [[functional-binding-names]]
-=== Functional binding names
+= Functional binding names
 
 Unlike the explicit naming required by annotation-based support (legacy) used in the previous versions of spring-cloud-stream, the functional
 programming model defaults to a simple convention when it comes to binding names, thus greatly simplifying application configuration.