refactor update architecture to "plug in"

1. Expresses an architecture to gather new posts and update them using app engine tasks, which are scheduled using cron jobs.  This same approach will be used to write data gathering plugins so we can collect impact metrics automatically. I intend to get one ready that pulls view data from blogger in time for the presentation at the GDE summit so we may invite many GDE's to write data gathering plugins (I use the word plugin loosely).

2. /tasks/new_gplpus is run daily and as the previous cron job gets new activities, this time for one gde at the time. 

The implementation is different in that we only merge AP is they are actual shares from another post, if they are not we will create a new AR and leave it to the GDE to decide how and why he merges AR's and their associated AP's. In order to do this, I process the new activities from oldest to newest.

3. /tasks/upd_gplus is run weekly and updates existing activities, similarly as above for one gde at the time.

The implementation is pretty much the same as previously. In particular we continue to ignore the fact that a #gde tag is removed from a gplus post, we consider currently that it has to be deleted in the front end, to be discussed at the summit.

4. ActivityRecord -> find_or_create as a function, is really the responsibility of the Business Logic (ie. the task plugin architecture) so I am moving it out of ActivityPost Endpoints class and attaching it to update_gplus Module in the name find_or_create_ar.

5. The API_KEY to access the GPLUS service is now obtained from secrets.json and the keys have been regenerated, so they are not what they where it the source code tree anymore.

6. The insert ActivityPost endpoint has been removed.

@Scarygami thanks for having a good look at this :)
I think we had plans to keep "inactive" GDEs in the Account list, but I think those shouldn't be included in the update task either, so maybe make the check:

    if account.type != "active":