Three possible viable approaches:
 1) TDB conversion approach. Read in TDB dump out LDIF (one-way)
  - samr.ldb: from tdbsam/smbpasswd, account_policy.tdb, secrets.tdb, group_mapping.tdb
  - registry.ldb: from registry.tdb
  - wins.ldif: from wins.tdb/wins.dat
  - smb.conf/ea's: generated from the old smb.conf + share_info.tdb
  - winbind.ldif: from winbindd_idmap.tdb (custom file format, not used 
										   by samba4 yet as it doesn't
										   have Winbind yet)

  (one-way upgrades can be done by using ldbsearch -a on these dynamically
  generated ldb's)
  Since TDB's are local, there isn't much point in writing back backwards 
  compatible data.

 2) samr "mapping" backend (alternative for samr.ldb) (two-way)
    This would allow users to keep mixed domains containing Samba3 and Samba4.

 3) The vampire way of doing things (one-way)
  - samba3 pidl backend 
  - Samba4 vampire + server side samsync support in Samba3
  - unixinfo (\unixinfo)
   - in Samba4 (client side)
   - in Samba3 (server side)
  - winsrepl (thru seperate pipe?)
  - enum/add shares (\srvsvc)
  - enum/add registry (\winreg)
  - enum/add printers (\winreg, perhaps also \spoolss(?))
  - convert smb.conf (using Jerry's registry hack)

(going with a combination of 1 and 2)

ldb mapping backend:


Upgrade process:
 - take libdir & smb.conf
 - read various tdb files / old smb.conf 
 - write new smb.conf (ejs)
  - list of parameters to keep.. generate some of the others
 - add generated LDIF (ejs). Call out to current provisioning

TODO:
 - move ini parsing stuff to seperate file param/ini.c