Fixes gh-148

There is only one version of amazon-kinesis-deaggregator available
in Maven Central, which is unfortunate because it brings in an
older version of the AWS events API, which in turn has a very bad
version range specification, causing the whole AWS internet to
be downloaded for each build.

I also made the deaggregator optional, which will help. Users that
want to include it shoudl consider doing the same exlcusion.

Fixes gh-171

Fixes #129

We can revisit this later, but I don't like the way it works at the
moment (too many dependencies in there and we only use a handful).

The current implementation of SpringBootKinesisEventHandler only handles
non-aggregated events. Attempting to process aggregated events caused
ungraceful failure.
This commit fixes that by de-aggregating any events before performing
conversion. Non-aggregated events are still handled transparently.
In addition, detection of Message<T> input is performed, and
output messages are wrapped accordingly.

- 1.5.10 to 1.5.11

- 2.0.0 to 2.0.1

This results in a better experience for users because the consumer
that they write is only applied to a Flux that is subscribed to
by the framework once. It gives better control over the flow of
foos, e.g. if some component wants to subscribe on a thread.

Avoids instantiating beans if not necessary, and allows user to
provide Function as a @SpringBootApplication (for instance), or
more generally as a source to the application context (as opposed
to being component scanned).

User can switch off source or sink behaviour (the default is to bind
to input and output streams), and then configure the name of a
supplier (for a source) or consumer (for a sink).

When a Supplier<Flux<Foo>> is composed with a Function<Foo,Bar>
the resulting handler (supplier) should have Flux as its output
wrapper still (the most general output wrapper type in the chain).

A Spring Boot 2.0 app should behave the same as a Spering Boot 1.5
app with this change. The key thing was to change the return type
of the FunctionController and move the computation of single
valuedness for the output there (instead of trying to do it in the
return value handler, which isn't used in Spring 5).

That was the samples still work with Spring Boot 2.0.0.

Fixes gh-157 (but we should add some tests)

Fixes gh-153

Since a function is wrapper in a FluxWrapper (and possibly also
an Isolated), the link is lost between the bean and the type
metadata without this change.

Makes it possible to support other "function" types in the future.
The user is always taking a risk with the lookup that the object
returned has the generic type desired (but that hasn't changed
with this commit). FunctionCatalog is a lot simpler as a result
and also a lot more flexible.

Signed-off-by: Kamesh Sampath <kamesh.sampath@hotmail.com>

Otherwise the explicit types from the function registration are
not used.

Fixes #109