Fixed a bug in the determination of ISO week number in Java

Previously, the week number of a Sunday was one too low because Sunday
is considered part of the previous week under ISO 8601 week date, in
which weeks start on Monday.

Furthermore, added two stopLoading() calls to calendar/App.js: previously,
whenever the user clicked on a date within the currently selected week,
stopLoading() was never called, and the UI appeared to be loading the
date information over a long (never-ending, in fact) time.

Also removed a TODO that is no longer relevant since Candide fixed the
corresponding bug in fluxtream/fluxtream-app/master:422b85def0.
Added support for computing an MD5 hash to HashUtils
Added API method (/api/bodytrack/photo/{PhotoStoreKey}) for requesting Fluxtream Capture photos (see BodyTrackController.getFluxtreamCapturePhoto()).  Also improved supported image detection and added ImageUtils.ImageType.
Added API method (/api/bodytrack/photoThumbnail/{UID}/{PhotoId}/{ThumbnailIndex}) for requesting Fluxtream Capture photo thumbnails.
The timeline photo dialog now uses the largest thumbnail (if available) instead of the full-res image.  Defaults to full-res image if no thumbnails are defined.
Fixed security hole when viewing Fluxtream Capture thumbnails
Merge remote-tracking branch 'upstream/master'
Fixed an exception caused by the move of getWeekNumber into DateUtils.js

Since getWeekNumber has been moved into DateUtils and changed to accept
three parameters instead of one, this call was previously failing.
Partially restored the prior timeline dragging/date change behavior

Previously, dragging the timeline caused the calendar to change its date
based on the min time of the timeline, and didn't include momentum.  I
mostly just restored the code that was removed from TimelineTab.js in
commit c1888e76ff, with a few updates to match the new navigation
scheme.  I still have yet to implement code to ensure that navigating
away from and then back to the timeline tab keeps the timeline tab
bounds consistent.
Fixed "pinkish hue" bug with generating thumbnail from image with an alpha channel.  Fixed by discarding the alpha channel.  Also now forcing all thumbnails to be JPEGs.  This lets us safely assume that the MIME type for thumbnails is always image/jpeg, and we don't have to inspect the image to determine the type.  Thus, faster.
Disable the Picasa connector
Merge remote-tracking branch 'upstream/master'
Fixed the bug in which refreshing the timeline lost the visible time

Previously, if the user tried to load a URL such as
/app/calendar/timeline/date/2012-11-01 by copy-pasting into the address
bar, the timeline appeared showing data from the most recent 24 hours,
not data from November 1, 2011.

The problem was that, if setRange (in Grapher.js) tries to set the date
range but the date axis hasn't been initialized yet, the function
just logs that there is no way to set the bounds on the date axis and
does nothing else.

The fix was to create a new onLoadActions property in a Grapher object
(again, in the Grapher.js file), and change the onLoad function to call
all the functions in the onLoadActions field.  This way, if someone calls
grapher.setRange before the date axis is initialized, the change is
applied during the onLoad callback, once the date axis has been
initialized.
Fixed a typo in Tab.js

The function onContentsRetrieved was misspelled as onContenetsRetrieved.
Better logging
Removed unused import
Cleanup
Automatic grapher update from commit QuantifiedSelf2012:bb7450b+
Added missing parameters to a function call in Grapher.js

Previously, the function only passed one argument (dy) to a function
that takes three parameters.  The code now passes all three arguments.
Fixed the bug that caused timeline movement to be lost on tab change

Previously, if the user panned or zoomed the timeline, and then switched
tabs, the timeline would be reset back to match the date range in the
page header.  The correct behavior is for the timeline to snap to the
date range in the page header only if the user (a) reloads the page or
(b) changes the date range in the page header.

I fixed this bug by adding a field to the Calendar object that records
whether the time range has been updated, by page refresh or change to
the date range.  This field is set to true whenever the range is
updated, and set to false whenever the timeline is snapped to that
range.  Furthermore, the timeline is only snapped to range if the
updated field is true.  This ensures that simply changing tabs doesn't
cause a snap to range, but refreshing the page or changing the date
range with calendar navigation actions does.

I also combined this new field with the start and end fields that were
previously on the Calendar object, to create a single timeRange field.
This is just a small refactoring for clarity, not a change in
functionality.  This change would work equally well if I had added a
timeRangeUpdated field to the Calendar object, updated the value in
appropriate places, and not touched Calendar.start or Calendar.end.