Refactor Core scripts

We should ask Crell about this, because I suspect that there's going to be a really nice, clean way of doing things with Symfony. Also, you might check into the installer rewrite - that will significantly change how this is handled.

Once we switch to the Symfony Generator, we should be getting back a URL that includes (or not) the base script that was used to get to the page. I think. :-) I need to check into that again. That is, the current trajectory would have index.php point to index.php, install.php point to install.php, etc.

For what it's worth, parts of update.php apparently believe this is the way the code works already:

function update_helpful_links() {
  // NOTE: we can't use l() here because the URL would point to
  // 'core/update.php?q=admin'.
  $links[] = '<a href="' . base_path() . '">Front page</a>';
  if (user_access('access administration pages')) {
    $links[] = '<a href="' . base_path() . '?q=admin">Administration pages</a>';
  }
  return $links;
}

I think the code comment is wrong though :)

Also, these scripts (install.php and update.php) already mostly use a special helper function to link back to themselves anyway, drupal_current_script_url(), since it's important that they maintain any query parameters which are set throughout the duration of the script, and that function helps them do that. So I'm guessing they wouldn't ever want to call url() directly to link to themselves (even if it worked), but rather at most have the internal behavior of that helper function call it... which would not be a bad thing since that function is a little broken anyway, #1433996: update.php doesn't work when Drupal is installed in a subfolder and RewriteBase is used.

As is evidenced by the discussion on #2017769: Links from update_helpful_links() should point to site root and not to update.php url now points to the currently executing script.

Updated issue summary.