Create chrome/browser/api directory. Move infobar delegates used by Autofill to the directory.

chrome/browser/api/DEPS

Index: chrome/browser/api/DEPS
diff --git a/chrome/browser/api/DEPS b/chrome/browser/api/DEPS
new file mode 100644
index 0000000000000000000000000000000000000000..90c085b0a9a7a0136cf29cab64d6b71ad35fc4f8
--- /dev/null
+++ b/chrome/browser/api/DEPS
@@ -0,0 +1,29 @@
+# The chrome/browser/api directory is for programming interfaces
+# provided by Chrome to Browser Components that run within Chrome.
+# Files here are not allowed to include stuff under chrome/browser
+# since that would leak implementation details to users of the APIs.
+#
+# APIs can be either pure-virtual to allow specialization at runtime,
+# or they can be non-virtual and specialized per platform (or
+# otherwise at compile time), or a mix of non-virtual and virtual.
+# The primary initial objective is to break Browser Components'
+# dependencies on implementation details, so non-virtual classes in
+# header files that do not expose any headers from chrome/browser
+# except for chrome/browser/api are acceptable.
+#
+# Note that for non-virtual APIs, there is an increased risk of an
+# implicit link-time dependency remaining from the user of the API to
+# the implementation.  We are accepting this risk initially, but plan
+# to write a new type of link-time or target-level set of dependency
+# rules to help us find such problems and reduce them over time.
+#
+# The directory structure under chrome/browser/api/ is a mirror of
+# those parts of the chrome/browser/ structure that APIs have been
+# extracted from.  Hence, an API defined in chrome/browser/api/x/y/z
+# is likely to be implemented in a directory chrome/browser/x/y/z.
+#
+# See http://www.chromium.org/developers/design-documents/browser-components
+include_rules = [
+  "-chrome/browser",
+  "+chrome/browser/api",
+]