Issue title: Accumulative sampling SPTWalker use wrong speed for time interpolation on edge in CAR/BIKE modes
 Issue body: Quote from [this thread](https://groups.google.com/forum/#!topic/opentripplanner-dev/sdKmyBXqvRI):

> I made a test on http://116.69.203.115/demo/master/marseille/ with the mode CAR and max time 0:30.
> It generates an isochrone where some accessible roads appears as islands. Some road sections farthest from the starting point are accessible while  nearest road are not as you can see on the image attached. I don't  understand how it's possible. Is there a way to avoid this?

![sample_auriol](https://cloud.githubusercontent.com/assets/959548/5162926/c8b9cd7c-73c5-11e4-8472-6074e945520c.png)

 Comments: 
 Comment 0: It's a bug (also known as a "feature") in the [code here](https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/analyst/request/SampleGridRenderer.java#L208).

Basically in this code I was assuming walking speed (off-road walking speed, 1 m/s = 3.6 km/h) to interpolate the time alongside road segment at various points along the road to generate the result, where we should have taken the car speed on the edge. We never saw that problem before because the issue only appear for CAR mode (which was not a top priority for isochrones) and only for long stretches of road. This interpolation is necessary as the data we have from the trip plan only contains a state for each vertex, so we have to interpolate back the data (time, etc...) alongside long edges (used for the "accumulative sampler algorithm").

In order to solve this, we simply have to take the real speed on the edge, given the current non transit mode of the end-states of the edge (to accomodate mixed modes such as P+R for example). Unfortunately this is simpler said than done, because effective speed on a given segment can depend on a lot of factors and is not necessarely available at the time we sample the SPT (shortest path tree). But we could take a good approximation by using the edge max. car speed for CAR mode, and default speed of the request for other modes. The longer the edge, the bigger the error; but for actual edges this should give good approximation. We should also make sure that the assumed speed is never _faster_ than the average speed to go from both end edges states (taking actual state time and edge length) to prevent discontinuity at one end of the edge.

 Comment 1: Should be fixed by the pull request #1626.

Please see an example which show CAR isolines starting on a motorway (notice the asymetry of the result):
![isoline_nantes](https://cloud.githubusercontent.com/assets/959548/5166396/c5d10664-73ef-11e4-95c8-9ff8e689dec5.jpg)

There are still the possibility of having unconnected result, when two road crosses each other. For different roads near each other, the sampling algorithm will average the various values for each sampling point, so you could end-up with a cut in a road segment (in the attached example you can see a cut at the bridge below "Saint-Herblain").

{'source': 'GithubIssues', 'repo_name_with_owner': 'opentripplanner/OpenTripPlanner', 'issue_id': 49870689, 'repo_stars': 1772.0}