Migration process review

Seeing #845 (closed) made me think again about the whole migration process in vtiger...

IMHO the entire migration process needs a serious re-think.

1. It really is not fit for purpose. 1a. I have ended up taking these migration files and hacking them so they can be run from the command line because for any vtiger system that is fairly large, running from a web browser just times out. 1b. It also means we can log the output (although the output data is ONLY designed to be shown in a browser window, e.g.
   rather than PHP_EOL)
2. Numerous bugs and errors remain which I have commented about on the dev list before 2b. Some parts are so slow and do not work in large databases at all (again I have mentioned these in the past)
3. Why are "Migration" scripts used during clean installations?
4. No way to recover for a partial migration - nothing is recorded or checked to see if it has already run
5. Some migration routines within these scripts will cause serious problems if run multiple times (see 4)
6. Some parts of these migrations scripts are repeated time & time again (see #845 (closed) for an example)
7. The way these migration scripts are written and designed means it is down to the developer of a new feature or function in a new version to make sure they write appropriate code in one or more of these migration scripts
8. The packaged modules have no version control. #845 (closed) could be easily fixed if all modules were installed using a common process which also made use of some kind of module versioning

I recommend we discuss a way to sanitise, re-factor and improve this whole process.