Conflict with uc_recurring - minor re-architecture

Hey, great module, does exactly what we needed it to do, however.. found a couple of issues with it that I had to solve, so I figured I'd post my fixes.

uc_recurring works by copying the order object and creating a new order each time it renews an order. It unsets the line items as part of this process, however, it has no knowledge of uc_add_donations additional $order->add_donation_amount, and doesnt know to unset it, thus replicating the donation from one order to the next. (fortunately it doesnt replicate the *charge*).

So, what I noticed is that instead of storing the donation as a line item in the database in the uc_order_line_items table, using the ubercart api, theres actually another table you are storing the donations in. I can see the utility in this if at some point there is other data to store alongside the donation, like "please make my donation anonymous" - however the uc_order_line_items does have a serialized "data" field where such stuff could be placed.

I have modified uc_add_donation.module to re-implement it so that it uses the default line_item storage. This solves the uc_recurring issue, and has additional benefits. Any contributed module that accesses the line item data will have access to the donation data, most notably uc_views - which would solve the question presented here: http://drupal.org/node/992144

To fully implement this change there would still need to be a hook_update in the .install that would insert the current contents of the uc_add_donation table into uc_order_line_items table.. so current users cant just plug this in. But we havent launched yet, so it will work for us.

Unfortuneately this patch is against the 1.3 release and not the dev branch, however I notice the only differences are that the dev branch checks if the order is 0, which this patch also does, as well as a change to the admin form, which I've incorporated as well.

Have a looksee..