add REST documentation for activity module

My preference would still be not mix the properties of multiple types into one model or repeat the various properties in multiple places. After some discussion with @simong, I think we have 2 options:

- Don't bother documenting all of the properties and just document the shared ones per model, relying on users using the `Try this out` button to see what exactly comes back. The upside is that we significantly reduce the chances of documentation getting out of sync. The downside is that it relies on the user trying the feeds and therefore edge cases could easily be missed.

- Achieve the enumeration of the different re-usable models by introducing an intermediary model. In practical terms, this would look something like this:

```
/**
* @RESTModel Activity
*
* ...
* @Property    {Target}         target                    Target of activity
* ...
*/

/**
* @RESTModel Target
*
* @Property    {ActivityUser}         (activityUser)                   Used when a user is the target of the activity
* @Property    {ActivityGroup}       (activityGroup)                Used when a group is the target of the activity
* @Property    {ActivityContent}     (activityContent)             Used when a content item is the target of the activity
* ...
*/

/**
* @RESTModel ActivityUser
*
* @Required    [displayName,id,oae:id,objectType]
* @Property    {string}        displayName             Display name for user
* @Property    {string}        id                      API URL for user
* @Property    {Image}         image                   Display image for user
* @Property    {string}        oae:id                  Unique identifier for user
* @Property    {string}        oae:profilePath         Path to user's profile in OAE
* @Property    {TenantInfo}    oae:tenant              Tenant of user
* @Property    {Picture}       oae:thumbnail           Thumbnail image for user
* @Property    {string}        oae:visibility          Visibility of user [loggedin,private,public]
* @Property    {string}        objectType              Type of target [user]
* @Property    {string}        url                     Full URL to user's profile in OAE
```

where `Target` is the intermediary model that lists the possible models that can be used/are expected. The advantage is that we can document all different scenarios and re-use existing models wherever possible using the `(...)` convention (cfr. `{...}` convention). The downside is that people looking at the response model will need to factor in the `(...)` convention and that we will be introducing quite a few intermediary models.


Before I started writing this up, I had a preference for the second approach. After having written it up, I no longer have a strong opinion. @stuartf @bp323 @sathomas : What do you think?