Calling (package-initialize) sooner during initialization

[Artur Malabarba]

On the "Customizable modes..." thread I suggested we run
(package-initialize) sooner than the way it's currently done. Right
now, it's called after loading the init file. Which means any user who
tries to customize an installed package by pasting some code into his
init file will be confronted with errors.
This happens A LOT.

Stefan kindly explains why it can't just be done before loading the init file:
> [...] the user may need/want to run some Elisp
> code of his own choosing *before* package-initialize is called.
> E.g. [...] set package-load-list and package-directory-list

But I'm asking that we try a little harder to find a better solution.
This package.el-induced "cannot find load file" error is the most
predominant issue I see people run into in the wild. Some people file
issues for this stuff on github (and waste developer time), others go
to the relevant forums, and others (I can only imagine) probably just
give up on configuring packages (or give up Emacs!) entirely.

So I hope we can try to converge on an actual solution instead of just
resigning to something that harms the majority of the users. I propose
here a couple of suggestions which still preserve the use-case outline
by Stefan, and I'm perfectly open to other ideas.
Even if we can't find an ideal solution, try to keep in mind how
absurdly unideal the current situation is.

Option 1) Check if the file `~/.emacs,d/.package-delay-init' exists.
If it does, just do it the way we currently do. If it doesn't exist,
do package-initialize first and then load the init-file. This
`.package-delay-init' file is not loaded, Emacs would only check if it
exists.

Option 2) Instead of us manually telling users to add
`(package-initialize)' to their init-files, we have Emacs do that
automatically. Similar to how `custom.el' adds a call to
`custom-set-variables' the first time you save a variable; package.el
could add a call to `package-initialize' the first time you install a
package. This would be a one-time-thing (and would take some
intelligent coding to prevent annoyiances).

Thank you all,
Artur