I reviewed your proposals, and they sound interesting. The first one especially made me think of something which we internally call "loop phase". 
It's related to more than just construction heuristics, but it is one way to approach "ruin and recreate" semantics in the solver. Essentially, the local search reaches a particular solution, then some code is run, the solution is partially or fully ruined, and the solver loop runs again on this new solution. See  for inspiration.
Doing this via a loop phase would require significant changes to the core of OptaPlanner, and I do think that - together with proving by benchmark data that the loop phase provides significant improvements on problems of all kinds - it could be a good master thesis.
(Another approach to the same problem would be to write some generic "ruin and recreate" moves; moves that understand how to ruin a solution and then how to rebuild it back up. This would have the benefit of being both closer to  and possibly more flexible. Also much much harder, as the construction heuristics would have to be run *inside* of a move.)
One thing where I would advise a different approach to the one you propose is the idea of a "PR at the end." This is not the best way to work together. Large code dumps are frowned upon, and likely will not be accepted.
If we can work together in an incremental fashion, step-by-step, starting with proper analysis of the problem and a thorough discussion of the selected approach, the chances of merging your code will be much higher. You should also know that the OptaPlanner project is very demanding in terms of code quality, and we have high standards on performance and test coverage as well.
If all of that sounds like an interesting project for you, then let's set up a meeting and let's get started.