How to manage features or pull requests in Train M

Our team is now moving to release train deployment model (http://thinking-in-code.blogspot.com/2010/07/train-model-of-software-development.html) and we need tools or method to manage how we merge Pull Requests and build new release.

Note: I will be using Git terminologies to explain the problem

With release train deployment model, the releases occur at fixed schedules and the features are pinned to a specific release. But the core idea with this model is that if a feature is not complete or specifically not bug free, that feature is not taken up in the coming release but scheduled for a later release.

With this in mind, we need some approach to manage Pull Requests and release builds with respect to following:

A build can be made with all the feature branches so that this build can be given for testing (QA). We do not want to actually merge this in our development or release branch. (why? The next point deals with it)
So if a feature is not zero bug (bug free), we would want to drop that feature. Hence we would actually merge only features with zero bugs and create new release build. In this way, a feature can easily be dropped. In terms of release train terminology, the feature would not board the release train.

What we have thought:

Assuming master contains the released code. Now the feature branches F1, F2, F3 are created on top of it.

Our automation setup, would merge these feature branches (from pull requests having "Approved" state) in chronological order in a temporary branch cut out from master and the setup will create a build from this temporary branch for QA Testing. (The merging in temporary branch would not close the PR)
Now, if only feature F1 and F3 are bug free on zero bug date, then PRs for F1 and F3 would be manually merged into master and a final release build would be created from master.

(Note: For point 1, if merge conflict arises, developers of individual branches would resolve it.)

Is there any Jenkins plugin or any other tool which can help us achieve the above. Please share some thoughts about this and suggest any better way of handling this problem.

Hence we would actually merge only features with zero bugs and create new release build

Well... the problem is that the result of the merge (meaning the "0 bugs feature branches" merged) can result in some bug!
A 0-bug feature branch (when develop in isolation) can have bug when considered in integration.

The general git workflow which does follow a release train model would be the gitworkflow (one word)

The idea is to merge the branches you want for the next release to an intermediate transient integration branch (that you can call "integration" or "dev" or "next"...).
That branch is re-created for each new release and allow for testing those feature branches in integration (together).

Then you merge only to master the ones you actually want for the next release.
You do not merge the integration branch to master. Only feature branches.

See more here and here.
I answered questions about that workflow here.