anchor.diff:  The above describes just a few use cases where you may need to use a single function to accept and/or produce
   multiple _streams_ of data. And that is the type of use cases we are targeting here.
   
  -Also, note a slightly different emphasis on the concept of _sreams_ here. The assumption is that such functions are only valuable
  +Also, note a slightly different emphasis on the concept of _streams_ here. The assumption is that such functions are only valuable
   if they are given access to the actual streams of data (not the individual elements). So for that we are relying on
   abstractions provided by https://projectreactor.io/[Project Reactor] (i.e., `Flux` and `Mono`) which is already available on the
   classpath as part of the dependencies brought in by spring-cloud-functions.
  
positive.code: <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-stream</artifactId>
      <version>${spring.cloud.strea.version}</version>
      <type>test-jar</type>
      <scope>test</scope>
      <classifier>test-binder</classifier>
  
negative.code: ----
  
  NOTE: The reason why `@EnableBinding` and binding interfaces are not required with functional programming model is because
  they could be derived from the type of functional interface itself. For example, _Processor = Function_, _Source = Supplier_
  and so on.
  
  
  