Fix PianoRoll playhead not moving during Record-Play

[regulus79]

This pull request fixes #7351 by changing the PianoRoll's connection from m_timeline to &Engine::getSong()->getTimeline(Song::PlayMode::Song), and additionally adding the signal positionChanged to the Timeline class.

The new signal is necessary because getTimeline() returns a Timeline, which does not have a positionChanged signal, while m_timeline is a TimeLineWidget which does.

This pr is marked as a draft, since after fixing the bug I found another one: When pressing stop after record-play, the piano roll play head does not go back to the start, but instead stops at its current position. Edit: I have decided to leave fixing that bug to a future pr, as it appears that it existed prior to the regression. Instead, this pr simply fixes the pianoroll playhead movement.

[messmerd]

Suggested change

	connect(&Engine::getSong()->getTimeline(Song::PlayMode::Song), SIGNAL(positionChanged(const lmms::TimePos&)), this, SLOT(updatePositionAccompany(const lmms::TimePos&)));
	connect(&Engine::getSong()->getTimeline(Song::PlayMode::Song), &Timeline::positionChanged, this, &PianoRoll::updatePositionAccompany);

We're trying to avoid using the SIGNAL and SLOT macros in new code

[messmerd]

Actually, there may be a better approach than adding a signal to Timeline... Let me think this over some more

[messmerd]

I don't really like how Timeline and TimeLineWidget have implemented their signals and slots for changes in position. I think ideally Timeline should be the model and only it should emit any positionChanged signals, while TimeLineWidget should be the view and its updatePosition slot should not emit any signals. The way it is currently, the TimeLineWidget is trying to do the job of both a model and a view, and that complicates things.

[messmerd]

@DomClark Do you agree with my assessment? It looks to me like a proper solution to this bug may require rethinking how the timeline position signals/slots are implemented.