I seem to have found a bug bug relating to date fields when other fields
on a form a invalid.

How to (I believe) repoduce:
- Have a node type that has a form with a date field
- Have an auditor for the same node that checks certain values and
raises a 'ValueError' if there is some problem

- Create or edit the node (ensuring there is no existing value for the
date field)
- Enter a date into the date field
- Enter a value into another fieldf that will cause a 'ValueError'
- Submit the form

The process should fail because the template engine(?) treats the date
value as a 'Date', when instead it is still a 'String'. See attached
traceback.

I have attached a potential fix/patch. I'm not sure this is the best way
to fix it, but it seems to do what I want.

Turns out that this issue is not related to displaying the date using
field(), but attempting to display the date in the history section of
the issue. When generating the "current state" the DateHTMLProperty
._value contains a str instead of Date which causes problems when
calling .plain()

The actual issue is therefore: values that have not been committed to
the database (due to an auditor error) are showing up in this history
when an auditor error occurs.

To reproduce this subtle issue (in a visual way):
 * Create a new issue that is assigned to someone ("demo")
 * Edit the issue, and un-assign it from anyone ("- no selection -")
 * Edit the issue once again, and:
    * assign the issue to someone ("demo")
    * delete the contents of the title (to trigger an auditor error)

The history should look like:
  2012-03-06 09:28:06	demo	set	assignedto: demo -> 
  2012-03-06 09:27:54	demo	create	

But instead it looks like:
  2012-03-06 09:28:06	demo	set	assignedto: demo -> demo
  2012-03-06 09:27:54	demo	create

A new patch that fixes the underlying history problem...

It checks the DB to see if the prop value exists before trying to fetch
it from the DB. This stops the value in the form from being fetched if
there is no value for the prop in the DB.

This probably isn't the most elegant solution, because it requires
hitting the DB twice if a prop value does exist in the DB (instead of
just once), but it is preferable to rewriting or duplicating a decent
amount of code.