[sql] Import reference version of SQLite 3.7.6.3.

[sql] Import reference version of SQLite 3.7.6.3.

In working on importing a newer version of SQLite, I found that I could
not find a copy of the previous version.  This makes it harder to figure
out if we have any mods which need to be tracked or unwound.

This import should be a non-event, since most of the files are identical
to the files in third_party/sqlite/src/ , so git will just add a reference.

BUG=340757
Committed: https://crrev.com/9cf3c6f4c0a79991a5ebacebee62adb0fb267861
Cr-Commit-Position: refs/heads/master@{#311378}

[Scott Hess - ex-Googler, 2015-01-13 18:59:51]

shess@chromium.org changed reviewers:
+ michaeln@chromium.org

[Scott Hess - ex-Googler, 2015-01-13 18:59:59]

There are no build-affecting changes in this.  I decided to just pull the entire
vendor checkout in after I realized that that's what tcmalloc does to deal with
the same general issue.  I didn't use sqlite_vendor/ or vendor/ because I wanted
to leave open the possibility of having two versions available at once during a
changeover.  That way instead of a giant CL with things coming in, things going
out, etc, there can be one rubber-stamp CL to land the new vendor version, a CL
patch src/ to use the new version, and a rubber-stamp CL remove the old vendor
version.  I don't think that increases the overall revision-control churn at all
(all of the same files come in and out, just at different times).

[michaeln, 2015-01-13 22:32:18]

rs lgtm

> There are no build-affecting changes in this.  I decided to just pull the
entire
> vendor checkout in after I realized that that's what tcmalloc does to deal
with
> the same general issue.  I didn't use sqlite_vendor/ or vendor/ because I
wanted
> to leave open the possibility of having two versions available at once during
a
> changeover.  That way instead of a giant CL with things coming in, things
going
> out, etc, there can be one rubber-stamp CL to land the new vendor version, a
CL
> patch src/ to use the new version, and a rubber-stamp CL remove the old vendor
> version.  I don't think that increases the overall revision-control churn at
all
> (all of the same files come in and out, just at different times).

[Scott Hess - ex-Googler, 2015-01-13 23:49:18]

The CQ bit was checked by shess@chromium.org

[commit-bot: I haz the power, 2015-01-13 23:50:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/826543003/20001

[commit-bot: I haz the power, 2015-01-14 00:59:54]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-01-14 01:01:02]

Patchset 2 (id:??) landed as
https://crrev.com/9cf3c6f4c0a79991a5ebacebee62adb0fb267861
Cr-Commit-Position: refs/heads/master@{#311378}