Packer feasible candidates list to priority queue

[RonZ13]

Description

[packer] Changing the vector of candidate molecules into LazyPopUniquePriorityQueue.

The class LazyPopUniquePriorityQueue is a priority queue that allows for lazy deletion of elements.
The elements are pair of key and sort-value. The key is a unique value to identify the item, and the sort-value is used to sort the item.
It is implemented using a vector and 2 sets, one set keeps track of the elements in the queue, and the other set keeps track of the elements that are pending deletion, so that they can be removed from the queue when they are popped.
The class definiation can be found in vpr/src/util/lazy_pop_unique_priority_queue.h

Currently, the class supports the following functions:
    LazyPopUniquePriorityQueue::push(): Pushes a key-sort-value (K-SV) pair into the priority queue and adds the key to the tracking set.
    LazyPopUniquePriorityQueue::pop(): Returns the K-SV pair with the highest SV whose key is not pending deletion.
    LazyPopUniquePriorityQueue::remove(): Removes an element from the priority queue immediately.
    LazyPopUniquePriorityQueue::remove_at_pop_time(): Removes an element from the priority queue when it is popped.
    LazyPopUniquePriorityQueue::empty(): Returns whether the queue is empty.
    LazyPopUniquePriorityQueue::clear(): Clears the priority queue vector and the tracking sets.
    LazyPopUniquePriorityQueue::size(): Returns the number of elements in the queue.
    LazyPopUniquePriorityQueue::contains(): Returns true if the key is in the queue, false otherwise.

Related Issue

This PR tries to resolve this issue: #2859

Motivation and Context

The original pack uses a fixed size vector to store the proposed candiates, and the candiates are sorted using insertion sort. If we want to increase the size, this data structure be less efficient than a priority queue.

How Has This Been Tested?

It has been tested using VTR tests and Titan tests. It shows no difference in post packing QoRs (CPD and WL).

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed