Create a dedicated Messages API

[laeubi]

Currently we have the BuildContext that it mixing two concerns:

1. Resource Operations (see Provide a new Resources API #76)
2. Creating Messages/Markers that inform the user in an IDE about issues on their files

For the Messages/Markers we even have some outstanding issues:

• Have a way to pass the plugin/id and an error code #57
• Messages must be clearable by an (plugin) id or properties #58
• Rethink deprecation of addError / addWarning and maybe even add addInfo and default implement those #44
• Make SEVERITY a enum? #40
• Please output INFO messages in DefaultBuildContext.addMessage #20
• UsePath instead of File in the API #47
• Due to a lot of parameters that needs to be passed it is always hard to use

due to backward-compatibility we can hardly change them or make any useful evolution.

Because of this we want a new API that is implemented in the following way:

• Create a new package org.codehaus.plexus.build.messages where we have a Messages interface
• Document it in the https://github.com/codehaus-plexus/plexus-build-api/blob/master/README.md#provided-apis section of the readme
• The Messages interface should have a method "clearAll" that clears all messages and a clear method that takes a path
• Beside that we want to have a builder pattern to construct a message in a more convenient, flexible and extensible ways: buildError, buildWarning, buildInfo that all delegate to a generic build that takes an enum for the type of message to build. Beside that each method must accept a Path for wich a message should be build
• There should be a DefaultMessages component that gets the BuildContext it injected in the contructor to proof the API is implementable
• The builder should be implemented in a class MessageBuilder that takes the type enum, the path and a Consumer of a constructed "Message" class that holds all collected parameter in one object, that way implementers of the API do not need to reimplement the builder, but the javadoc should state that this is usually nothing client code will call
• For all other current parameters the builder needs to have a appropriate method (e.g. line(int), column(int), message(String), cause(Exception)) that return the builder for chaining
• the MessageBuilder#create() method will the create a message object and inform the consumer, where the DefaultMessages implementation should log the message and call the old message API in the BuildContext, clearAll will be a noop here