[enhancement](merge-on-write) consider version count on size-based cu compaction policy

[zhannngchen]

Proposed changes

Issue Number: close #xxx

For MoW table, if there's too many versions, the delete bitmap will grow to a very big size, which may cause the tablet meta too big and the save_meta operation too slow.
If the rowset should not promotion according to it's disk size, we should also consider it's version count.

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[zhannngchen]

run buildall

[hust-hhb]

LGTM

[doris-robot]

TeamCity be ut coverage result:
Function Coverage: 36.24% (8156/22507)
Line Coverage: 28.34% (65300/230392)
Region Coverage: 27.06% (33819/124993)
Branch Coverage: 23.87% (17251/72258)
Coverage Report: http://coverage.selectdb-in.cc/coverage/cc8fd9041b791dd97168299cc2259ea7122a4378_cc8fd9041b791dd97168299cc2259ea7122a4378/report/index.html

[doris-robot]

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 46.06 seconds
stream load tsv: 583 seconds loaded 74807831229 Bytes, about 122 MB/s
stream load json: 20 seconds loaded 2358488459 Bytes, about 112 MB/s
stream load orc: 64 seconds loaded 1101869774 Bytes, about 16 MB/s
stream load parquet: 32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select: 29.2 seconds inserted 10000000 Rows, about 342K ops/s
storage size: 17162460037 Bytes

[hust-hhb]

LGTM

[github-actions]

PR approved by anyone and no changes requested.

[liaoxin01]

LGTM

[dataroaring]

LGTM

[github-actions]

PR approved by at least one committer and no changes requested.