Resolves #180

This can be reverted in 1.1. The compiler relies on being able to
bind itself to @ConfigurationProperties and the APIs changed for that
in Spring Boot 2.0.

Fixes gh-177

They were a remnant from teh time when the mapping implementations
lived in the web module.

Fixes gh-176

Otherwise webflux apps break when they include our BOM, even if they
don't even use spring-cloud-function.

...in case it is needed elsewhere (see gh-151)

Also provide ability to run with `Flux.interval(Duration)` in
compiled scripts

Fixes gh-174

Flux.from() is cheap and can be used to marshal the inputs everywhere
internally. With this change users ought to be able to register any
function of any Publisher type.

Using this strategy libraries could be developed for supporting
Flux-like libraries (e.g. kstreams) that are not actually
reactive streams implementations.

It tends to pop back into function apps where it is not needed
otherwise. Users that want to use the library need to import
the FunctionConfiguration directly using the
@EnableFunctionDeployer convenience annotation..

Instead of an app, it is now a library with some utilities
(principally ApplicationBootstrap) for launching a Spring Boot
application, extracting a function, and registering it in the
FunctionRegistry.

If an isolated function doesn't have Message in its classpath, we
will never actually need to instantiate that class. This change
makes sure we check first.

Fixes gh-156

See gh-170

There is now a JsonMapper strategy with implementations and
autoconfiguration for Gson and Jackson. If Jackson is present
it is preferred (just like in Spring Boot).

Fixes gh-150