The original design of this had some issues:

1) forced targets to be importable via 'buildbot.cbuildbot', rather
  than the proper/full 'chromite.buildbot.cbuildbot'.  Scripts worked
  around this, but it's an unwanted limitation.

2) That importation requirement means that within the chroot, we've
  had to export cros_sdk *and* cros_sdk.py in the PATH.  This is
  undesirable clutter, and introduces potential errors as scripts
  localize themselves to cros_sdk.py rather than invoking cros_sdk
  (the consumers should be agnostic to the language the tool is
  written in).

3) chromite_wrapper enforced assumptions about python namespace w/in
  the targets- specifically that 'main' must always be invokable
  without any arguments.  This limits refactoring/cleanup in chromite
  via having to support ancient API assumptions (api's that weren't
  public); modern chromite has repurposed main changing the prototype,
  and using it's own wrapper doing signal handler setup, and general
  framework behaviour.  Longer term, that 'main' functor is unlikely
  to even exist.  The strong coupling chromite_wrapper forced limits
  are refactoring possibilities.

4) In modern chromite, all user consumable tools are now required to
  exist w/in chromite/bin/, and be executable and invokable.  This is
  what we want going forward.

5) Implied we want chromite_wrapper used w/in the chroot; we don't,
  thus drop all CROS_WORKON_SRCROOT awareness.

6) Exposed a chromite_wrapper invokable (that didn't work) into the
  PATH outside the chroot; this is resolved via moving it into a
  support directory and repointing symlinks to it.

At this point, if it's working with a modern chromite checkout the
script is a simple execv pass thru.  If it isn't, then it will fallback
to the old import trickery.

This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*,
basically all branches w/in chromite without issue.




git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98