PropertyDataStore history support

Implement history support for PropertyDataStore (based on ResourceID http://docs.codehaus.org/display/GEOTOOLS/ResourceId).

Why:
1. PropertyDataStore is handy for testing GeoServer
2. It would be good to have a reference implementation of ResourceId that does not require the setup of "GeoGit"
3. Versioned PostGIS is stuck

The downside is that it is still based on AbstractDataStore.

Implementation approach is to use a side car "foo.history" file. The file can be added to during commit() using simple append from the transaction state diff.

In the interests of keeping this simple we will use a format similar to that provided by the RFC. We will use a "timestamp" created during commit to mark up each entry. This will serve as our magic "version" string required by ResourceId; it will also serve to let us handle the data range based a queries.

fid|version=value|value2|value2|value3

We have a number of ResourceID scenarios to handle:

1) Query all history for a specific FID

This is easy we can can traverse the history file in order; be remembering the "last" version we will be able to return the correct ResourceID information with a date range:

fid1|version1=value|value2|value2|value3
fid1|version2=value|value2|value2|value3
fid1|version3=value|value2|value2|value3
fid1|version4=value|value2|value2|value3
fid1|version5=value|value2|value2|value3

From the above example:

• "version5" is the latest value represented in the main property file.
• When we return a ResourceID for index 3 we will build a ResourceId using:

  new ResourceIdImpl( fid, String.valueOf(version),new Date(version), new Date(previousVersion));

2) Query a specific "index"

Handled in a similar manner as above; in this case we will need to count the number of times fid encountered in order

3. Query using "previous" or "next" or date range...

These ones require us to hold on to the previous unparsed feature content; on the off chance it ends up being the one requested (i.e. via previous or date range).