Improve custom class loading failure handling

Improve custom class loading failure handling

For background, see
http://code.google.com/p/android/issues/detail?id=13389

We currently both load and instantiate custom view classes under the
same try/catch block, and if there is a failure, the user is informed
that the class could not be -found-. However, in many cases the real
failure is in actually -instantiating- the class, so telling the user
that the class could not be found is misleading and can make the user
hunt down library dependencies, checking jar contents, etc.

This changeset improves the situation in the following ways:

- The code to load and instantiate are handled separately, and the
  list of missing classes is kept separate from the list of
  uninstantiatable classes.

- The error display in the layout editor lists these two categories
  separately.

- For instantiation errors, we dig up the root cause and log that
  one. The error display points to the Error Log for more details.

- If the class looks like it might be a custom view class (rather than
  a loading or instantiation failure in one of the Android or Add-Ons
  classes) then the error message also includes a tip about using
  View.isInEditMode to try to do less work for design time rendering.

Change-Id: I947ad91e0d7973e9c3aefed1824f61c92c5fb1ed