Idea: "headless" tables

@twerth and I discussed several scenarios related to #63 and https://github.com/infinitered/rmq/issues/232. One of the sticking points is collections or sets of data and how to represent those on a screen. Todd and I agree that tables are underutilized as child views, and I'd like to make that easier.

I have this concept of a "headless" table view. ProMotion makes it easy to make a `PM::TableScreen` subclass, but what if we could do this in a normal screen:

``` ruby
class ContactScreen < PM::Screen
def on_load
append email_view, :emails
end

def email_view
@email_view ||= build_table_view([{
title: "Email addresses",
cells: @emails.map do |email|
{
cell_class: SomeCustomClass,
title: email,
action: :tapped_email,
arguments: { email: email }
}
end
}])
end

def tapped_email(args={})
args[:email] # => some email
end
end
```

No explicit `PM::TableScreen` subclass would be necessary. All events would be passed through to the parent screen, and the UITableViewController instance would be automatically built, added as a `childViewController`, and managed from your current screen instance. These things are usually pretty boilerplate anyway, so it makes sense to have a helper for this.

Thoughts?

Start by reviewing the existing PM::TableScreen subclass workflow and the related discussion in issues #63 and infinitered/rmq#232. Define the supported headless-table API, event forwarding behavior, and childViewController lifecycle before determining what tests or implementation changes are needed.

Written by the indexing model from the issue text.