Added loop point support to sf::Music

After working a bit with SFML, I noticed that I couldn't set any custom loop points for sounds, and I need them for a game I'm working on. I spotted issue #177 sitting around, so I figured I would try implementing myself.

For sf::Music / sf::SoundStream, I added a feature to detect a loop point and cut off the streaming of the buffer, and a pair of virtual functions that can allow sf::SoundStream to let its derived class decide where to seek upon looping. It's accomplished entirely within those two classes without doing anything too funny with OpenAL, and I'm happy with what I managed to accomplish with it.

For sf::SoundBuffer / sf::Sound, I ran into some more constraints. OpenAL-Soft has a way to set loop points, but it's not a well-documented feature, and it is also a buffer trait, rather than a source trait. It has a few more restrictions on the allowable values compared to the Music version because of this. It uses an "enum" value called AL_LOOP_POINTS_SOFT defined in "alext.h", which was present in SFML but not included, and I figured it was fair game to use. If not, then I can take the SoundBuffer implementation out.

The inline documentation will explain any interface differences, but they're roughly the same, with getLoopStart(), getLoopEnd(), setLoopPointsFromTime(), and setLoopPointsFromSamples(). Three of those work with sf::Time, to keep everything consistent, the fourth is if you have an exact sample position you want to use.

I hope this isn't frowned upon, but for testing, I augmented the SFML Sound Example to include some additional playings of the resource sounds, and demonstrating some of the extra features of the Music implementations. At least it should be easy to build and test. If any modification or more proof-of-functionality is needed, please let me know!
`std::size_t` may be smaller than `sf::Uint64`. If it is a 32 bit type, then "only" 27 hours of music can be played at 44.1kHz. With higher sample rates, it's even less. Since we don't know how the music is possibly used, and it costs nothing to use 64 bit types, I'd suggest to stay with `sf::Uint64`.