#54913, problem with checking filesize during uploading if user belongs into more than one role, patch by dopry

- Patch #31354 by Junyor et al: move node revision information for files to a separate table. (Today's critical bugfix #1.)

- Patch #39778 by chx: obliterate nodeapi op form in favor of the forms API's way of doing things.  Tested with help from webchick.

- Patch #35121 by m3avrck: fixed problem with list and description values aren't saved for uploaded files.

  TODO:
  + The contact.module was broken; a new patch for contact.module is needed.
  + Documentation is needed.
  + The most important modules need to be updated ASAP.

  (Modified the form a bit.)

  Comment from Steven: It does this by redirecting the submission of the form to a hidden <iframe> when you click "Attach" (we cannot submit data through Ajax directly because you cannot read file contents from JS for security reasons).  Once the file is submitted, the upload-section of the form is updated.  Things to note:

    * The feature degrades back to the current behaviour without JS.
    * If there are errors with the uploaded file (disallowed type, too big, ...), they are displayed at the top of the file attachments fieldset.
    * Though the hidden-iframe method sounds dirty, it's quite compact and is 100% implemented in .js files. The drupal.js api makes it a snap to use.
    * I included some minor improvements to the Drupal JS API and code.
    * I added an API drupal_call_js() to bridge the PHP/JS gap: it takes a function name and arguments, and outputs a <script> tag. The kicker is that it preserves the structure and type of arguments, so e.g. PHP associative arrays end up as objects in JS.
    * I also included a progressbar widget that I wrote for drumm's ongoing update.php work. It includes Ajax status updating/monitoring, but it is only used as a pure throbber in this patch. But as the code was already written and is going to be used in the near future, I left that part in. It's pretty small ;). If PHP supports ad-hoc upload info in the future like Ruby on Rails, we can implement that in 5 minutes.

All node revisions were stored in a serialized field in the node table and retrieved for _each_ page view although they are rarely needed. We created a separate revisions table which would be in principle identical to the node table, only that it could have several old copies of the same node.  This also allows us to revision-related information, and to provide log entries to non-book pages when a new revision is being created.

TODO:

1. Provide upgrade instructions for node module maintainers!
2. Upgrade modules that implement node types.
3. Provide an upgarde path for revisions.  Dependency on the upgrade system.

- Alternative solution for #28721: expand "File attachments"-group on node edit form when files are attached.