BackgroundFunctionExecutor.java failes to detect type when sub-classed

Error Condition

>Exception in thread "main" java.lang.RuntimeException: Could not determine the payload type for BackgroundFunction of type com.example.MyFunctionHandler; must implement BackgroundFunction for some T at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:140) at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:113) at com.google.cloud.functions.invoker.runner.Invoker.startServer(Invoker.java:256) at com.google.cloud.functions.invoker.runner.Invoker.main(Invoker.java:127)

Occurs when `BackgroundFunction` is subclassed:
> `public abstract class MyExtendedBackgroundFunction implements BackgroundFunction`

and
> `public class MyFunctionHandler extends MyExtendedBackgroundFunction`

In the class mentioned, the following function fails to detect sub-classed BackgroundFunction type:

```
static Optional backgroundFunctionTypeArgument(Class> functionClass) {
// If this is BackgroundFunction then the user must have implemented a method
// accept(Foo, Context), so we look for that method and return the type of its first argument.
// We must be careful because the compiler will also have added a synthetic method
// accept(Object, Context).
return Arrays.stream(functionClass.getMethods())
.filter(m -> m.getName().equals("accept") && m.getParameterCount() == 2 && m.getParameterTypes()[1] == Context.class && m.getParameterTypes()[0] != Object.class)
.map(m -> m.getGenericParameterTypes()[0])
.findFirst();
}
```

This fails for described `MyFunctionHandler`.

The intent is to add common boilerplate handling for a couple of functions which is common to all. A separate abstract function is employed, but the function fails to load because the type is not determined.

Temporary workaround is to re-implement `accept()` with the type in the sub-classed object with the type, but is inelegant.