Optimize new write-ahead-log

[CGodiksen]

Some features and optimizations were left out on the initial PR for the write-ahead-log to avoid having too much in a single PR. This issue contains a list of tasks that can be done to further optimize and add features to the new write-ahead-log

• Make it possible to control threshold for when to truncate and rewrite WAL file.
• Make it possible to turn off WAL.
• Delete based on size instead of batch count for more consistency.
• Maybe handle spilled buffers with WAL.
• Handle data transfer and other operations with WAL.
• Look into if the WAL should be used for normal tables.
• Look through the code and check for optimizations and simplications.

When a task in the list is started, we should consider moving it to a separate issue.

[skejserjensen]

@CGodiksen and @chrthomsen since we now created multiple issues that provide an overview of multiple isuses that works towards a common goal, should we formalize how they are structured and named? For example, Apache use the label epic for such issues as described here. I do not suggest that we fully implement this entire issue setup as it is designed for Apache scale projects and for Jira, but maybe we could create an epic label and link epic issues that provide an overview to sub-issues that provide details about a specific part as Apache DataFusion does as shown here.