Fixes wrong schema when adding an expiration that contains microseconds

In the case we want a different expiration date on any role, we are
adviced to do this:

  repo.role.expiration = datetime.datetime(some value).

In the case we want to use a date somewhere in the future, a normal
approach would be to use time deltas:

  repo.role.expiration = datetime.today() + timedelta(weeks=x)

If we use this method we won't be able to set the value since we are
most probably producing a datetime object that contains *microseconds*.
According to the python specification, the timestamp produced will
contain the microseconds value unless it is 0.

The simple fix for this issue is to force the microseconds value to be 0
before working with the datetime object.
Updated test case for the expiration setter

The test case for the expiration setter now includes a set case in which
the microseconds value is forced to be one. This is likely to happen
when users try to set expirations using datetime.datetime.today() or
functions that return the actual clock, which have microsecond
resolution.
Updated test case for the expiration setter (microseconds truncation)

The new test tries to make the fact that the datetime object given will
contain microseconds. It also tests for the fact that the microseconds
value is truncated after being set.
Updated side effects in the repository tool expiration setter

The expiration setter's docstring now mentions the fact that the
microseconds value in the given datetime object will be discarded if it
is non-zero.
Merge pull request #213 from SantiagoTorres/expiration_timedelta_fix

Fixes wrong schema when adding an expiration that contains microseconds