Implement parsing "tweaks".

[evought]

As per #92, we are building up a number of post-parsing "tweaks" being performed on VCards to handle legacy VCards or obsolete properties/parameters. As these tweaks build up, the logic is starting to get tangled and there arises a need for the client code to select which tweaks are performed on which imports, especially if the caller has better information on the source of the cards (e.g. Outlook v. Evolution v. Apple AddressBook) than we do.

This issue is to implement an ImportTweak (or somesuch) which can be applied to a VCard post-parsing but prior to the return of parsed VCards to the caller. These structures need to have:

• A test to determine whether a specific tweak is applicable, possibly named for consistency with FilterIterator's accept() method.
• A method to apply the tweak to the VCard. This action may generate additional VCards in the case where the obsolete property may contain embedded cards (e.g. AGENT or similar X-properties in common use).
• A way to constrain ordering, if necessary. That is, some tweaks may need to be run only after another tweak has been performed. For example, translation of legacy TYPEs such as PREF or MEDIATYPEs which now have their own parameters must be performed after bare VCard 2.1 TYPEs have been extracted. I am thinking that VCardParser will keep a list of tweaks which have already been performed in a specific pass and will check that list against any dependencies declared by a tweak before testing or performing it.
• A name by which a specific tweak may be performed. This is needed for declaring/tracking dependencies and for configuring which tweaks will be performed.

Optionally, we may start thinking about a registry or hints for tweaks which may be applicable to specific kinds of imports (e.g. for importing from Outlook).

[evought]

As regards order of application, it looks like there are two types of 'tweaking' going on:

1. Tweaks of parameter values prior to instantiation of a PropertyBuilder and applied to the VCardLine. These must happen before the whole card is parsed as they affect constraints on the Properties themselves (e.g. which TYPE values are permitted) and parsing may fail if they are not performed. The PREF tweak is a good example.

2. Tweaks of property values after PropertyBuilders have been applied and the initial Properties have been established, but before the VCard is returned to the caller. The AGENT tweak is a good example of this.

It may be, therefore, that we are looking at two classes: ParameterTweak and PropertyTweak.