Reconsider trainingData.startRecording()

@fabian Brought up a point about the trainingData class, and its current, stateful API.

It does this:

trainingData.startRecording("myLabel");
trainingData.addElement(element);
trainingData.stopRecording();

That could cause problems if these functions aren't called in the right order. A safer API would be:

trainingData::phrase *myPhrase = trainingData.createPhase(); //returns a pointer to a phrase
myPhrase.addElement(<element>); 

@francisco Here's some user feedback on our API.

Thanks @MikeZ

I like this design. It seems more foolproof and compact.

It's not immediately obvious to me how to increment the uniqueId if the addElement() function is part of the phrase class. The lazy approach: "Do we need per-element id's?"

changed title from Recondsider trainingData.startRecording() to Reconsider trainingData.startRecording()

I checked in a version to develop that doesn't allocate ID's.

added Ready label

mentioned in issue #46

Related to #46

added In progress and removed Ready labels