Some updates to the FacebookRealTimeUpates framework. Not finished.
Check in of the last version of generated classes before generation failed to work (see http://ondotnet.deap.nu/2011/03/facebook-documentation-requires-login.html)

Major changes:
- Added the namespace Facebook.RealTyimeUpdates, a first version of support for working with caching and the Real-time Updates api. This affects how the classes are generated. For now, only connection properties are supported. I will cover this more in a future blog post at http://ondotnet.deap.nu.
Minor changes:
- Changed the DataContainer so constructor is used instead of method to initialize an empty datacontainer.
- Changed how generated files are named.
- Added counters in the GraphEntities.tt file that are output in main generated file, containing info on what is generated.
- Changed generation of "first level classes" so that ID property or at least one connection property is required for the class be generated with inheritance from GraphEntityBase.
- Generated a SetUserAccessToken method in each class that inherits from GraphEntityBase. It sets the UserAccessToken property and returns the current instance, making it easy initate with access token but keep working with the class instance (think jQuery Chaining)
- Added constructors and moved the ID property to the GraphEntityBase class. ID properties will not be generated.
- User.Partial.cs contains a commented code block showing how each property is now generated.

Corrections before push.

Taking a stab at generationg strongly typed classes from Facebook online documentation.
Do this:
1. Open up the Facebook.Entities.csproj-file in Visual Studio.
2. Locate and open the GraphEntities.tt file and change the path to HtmlAgilityPack.dll so that it is correct, it must be fully qualified.
3. Save the .tt file to generate the classes.
4. Do NOT check in the generated files to source control, it can get messy...
The .tt file might be a bit messy and probably needs some error handling. But I don't think the amount of work arounds are too much and I'm fairly pleased with my approach of
falling back on dynamic types when the type cant be inferred from documentation. When that happens "Dynamic" is appended to the property name so that the "desired name" is free
to implement in partial class definition.
See notes.txt for some feedback I might send to facebook and some other thoughts.
Another thought I had is to parse the "Publishing" part of the documentation to create a static Publish method in each class (maybe even som overloads), could be neet to be able to call Post.Publish(....).

- Added templates