Update onReceiveContent() logic for app vs platform processing

Previously onReceiveContent() would only invoke the app-configured
callback if the MIME type of the content matched one of the declared
MIME types for the callback. This change updates onReceiveContent()
to always invoke the listener if one is set (regardless of the MIME
type of the content). To delegate processing to the platform, the
app's listener can return some or all of the passed-in content. To
make this easy for apps to implement, the Payload class and its
Builder now provide some convenience methods to conditionally
partition the content.

Reasons for this change:
* Checking the MIME types could be an expensive operation. On SDKs prior
to S, ClipData does not keep track of the MIME types of individual
items, so for a ClipData that contains multiple items, checking the MIME
types requires making at least one RPC call per item.
* Allowing the listener to delegate processing to the platform via its
return value enables us to limit the API surface (we don't need to
expose TextViewOnReceiveContentListener as a public API, nor equivalent
classes for other types of views such as WebView).
* An app that wants to customize the platform behavior for coercing
content to text would previously need to declare "*/*" as the MIME type
for the callback (in order to be invoked for all content). But this
would make it impossible for features to know whether the app would
actually accept a particular type of content or just coerce it to text
(e.g. should the soft keyboard show GIF suggestions when the declared
MIME type is "*/*"). With the new logic the app's listener is always
invoked and can decide which content to process vs delegate to the
platform vs reject completely.

Bug: 170191676
Bug: 152068298
Test: atest CtsViewTestCases:ViewOnReceiveContentTest
Test: atest CtsWidgetTestCases:TextViewOnReceiveContentTest
Test: atest FrameworksCoreTests:TextViewOnReceiveContentTest
Change-Id: Ie48b6fe0b2ae4b014c371b5dc40248221947c6bf