Fixes #73 - Very long load times on event pages

My client insisted I look into the cause of the API slowdown in #73 (closed). It ended up being fairly simple.

The API wrapper adds the "registered_participants_count" to every returned event. If you use getsingle, it gets this by (correctly) calling CRM_Event_BAO_Event::getParticipantCount(). However, if you use get, it calls Participant.get to get the result count.

This has 2 problems:

• This doesn't give the same value as getParticipantCount(), because some registrations aren't counted against the available spaces. E.g. if I have a class with 25 open registrations, registering the teacher with the "Teacher" role shouldn't count against the 25.
• This means that every result in Event.get will make a call to Participant.get. So if you have 200 events, you're not making 1 API call, you're making 201.

There's a relatively little-known feature of API3 Event.get. If you pass the parameter is_full, and the event has a registration cap, it will return a value available_spaces. This a) gives a correct count, b) saves you all those additional API calls. This resolves the performance issue.

@BohdanDmytryshyn please review and let me know if you agree this is the correct fix?