Better trivial function identification in WARP

WARP tries to identify trivial functions to force constraint matching, this is what prevents trivial functions from matching random functions that don't have more than one possible match. For example the following function:

10004860  68484f3a10         push    data_103a4f48 {var_4}
10004865  b9984f3a10         mov     ecx, data_103a4f98
1000486a  e831c20700         call    sub_10080aa0
1000486f  6840962210         push    0x10229640 {var_4}
10004874  e8f06a1f00         call    _atexit
10004879  59                 pop     ecx {var_4}  {0x10229640}
1000487a  c3                 retn     {__return_addr}

Will match with:

[WARP] ?CleanupTopologyInformation@ResourceManager@details@Concurrency@@CAXXZ (98891602-4774-52eb-b4ca-ff23c8d6b104)
[WARP]     CS _free (f29d4b0d-29ef-5957-85fa-9fdbab6b0a1a)
[WARP]     ADJ _free (f29d4b0d-29ef-5957-85fa-9fdbab6b0a1a)

As seen above, there is only one possible match, and because the length is greater than analysis.warp.trivialFunctionLength (default of 20 bytes), the function will match without checking the constraint.

Of course the user can raise the setting listed above, but the primary issue here is the fact that our definition of a "trivial" function goes as far as the length of said function, rather than for example, the number of basic blocks.

We should extend WARP's definition of a trivial function to include things such as the number of basic blocks, the number of calls, and other broad metrics that make sense to include.