kuangmarkeleven/issue 61 escape unsafe characters in uri templates

fix issue #61 - escape unsafe characters in uri templates

To add this improvement required the introduction of a resolution annotation that is added to source annotation in order to provide resolution information for the associated warning or error. The production of a resolution is controlled via a new parser option "ResolverWarningsAndErrorsOption", this invokes the resolution service post source parsing.

Changed files:
ResolutionService.h - this is a new file and contains the code for resolving warnings and resolutions. This consists of the resolution service which incorporates a list of annotation resolvers. Each annotation resolver is a class that contains the code to resolve one type of resolution or warning. The annotation resolver determines which warning/error it can resolve by inspecting the code and subcode of the warning or error passed to it. Currently there are resolvers for the square bracket warning, the spaces warning and the invalid characters warning.

SectionParserData.h - an addition is made to the BlueprintparserOption enum for the new ResolveWarningsAndErrorsOption parser option.

SourceAnnotation.h - the new ResolutionAnnotation struct is added here along with the typedef for a collection of ResolutionAnnotations. SourceAnnotation is altered to include a collection of ResolutionAnnotations and a subcode is also added so that warnings and errors can be identified via a combination of code and subcode, constructors are altered to include subcode. A new enum is added to provide subcodes for the UriTemplateWarning.

UriTemplateParser.cc - subcodes are added to the warnings and errors created in the parsing process.

snowcrash.cc - added the code to produce resolutions to warnings and errors if the parser option exists. Also amended Error creation to include subcodes.

test-Resolutions.cc - new tests for resolutions covering square bracket resolution, spaces resolution and single and multiple invalid character resolution.

See my comments above. This seems like an overkill. It shouldn't be needed to allocate (and deallocate this manually). Just create it on the stack.