Improve Tabledrag Integration with the Form API

With the addition of tabledrag.js, Drupal made a huge leap in terms of usability, and even a developer like myself appreciates the benefits when I go to accomplish a task like enabling a block. However, as a relatively brand new feature, there is still a lot that can be done to make it easy for a developer to create forms using tabledrag.

While this is primarily an issue for a developer, to some extent it's an end-user issue, too. If it is easier to replicate forms created with tabledrag, more contributed modules will have user interfaces that look like the 6.x version of the block form, not the 5.x version. I know usability is a big concern for Drupal 7.x, and in a culture where we say, "There's a module for that!" usability does not just entail making Drupal more usable, but making it easier for developers to design usable contributed modules.

drupal_add_tabledrag function is always called from a theme function or template, and the theming requires some very specific modifications to be made to the table. As it stands now, there are several issues with this:

1. It partially defeats the purpose of having a Form API. Ideally, developers should specify all the different regions, all the items, which item by default goes into which region in what order, etc. Then instead of doing additional theming, we just pass it off to the Form API and let it make a lovely form for us.
2. Despite its complexity, the use of tabledrag has very little documentation aside from an entry in the Drupal API. And the complexity of tabledrag would require a large amount of documentation for developers to understand it well. Even as a developer who knows many APIs in depth and have written modules using more advanced features like node grants, I still don't understand much about tabledrag. Integrating it with the Form API would make documentation a whole lot easier and lower the learning curve to use this feature — because we all know that Drupal was very easy to learn when we first picked it up :)
3. The fact that most of the work to use tabledrag is done while theming the form. It's a little too much to ask of a web designer with not as much coding expertise, and its also a little much to ask of the programmer with not as much design expertise. It feels like the line between generating data and presenting data is being partially obscured here.