Function to create scale bar

[whelena]

Description

Add scalebar option to tree plots

Closes #144

Checklist

• This PR does NOT contain Protected Health Information (PHI). A repo may need to be deleted if such data is uploaded.
  Disclosing PHI is a major problem¹ - Even a small leak can be costly².

• This PR does NOT contain germline genetic data³, RNA-Seq, DNA methylation, microbiome or other molecular data⁴.

• This PR does NOT contain other non-plain text files, such as: compressed files, images (e.g. .png, .jpeg), .pdf, .RData, .xlsx, .doc, .ppt, or other output files.

  To automatically exclude such files using a .gitignore file, see here for example.

• I have read the code review guidelines and the code review best practice on GitHub check-list.

• I have set up or verified the main branch protection rule following the github standards before opening this pull request.

• The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)]-[brief_description_of_branch].

• I have added the major changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.

Footnotes

1. UCLA Health reaches $7.5m settlement over 2015 breach of 4.5m patient records ↩

2. The average healthcare data breach costs $2.2 million, despite the majority of breaches releasing fewer than 500 records. ↩

3. Genetic information is considered PHI.
   Forensic assays can identify patients with as few as 21 SNPs ↩

4. RNA-Seq, DNA methylation, microbiome, or other molecular data can be used to predict genotypes (PHI) and reveal a patient's identity. ↩

[whelena]

Creating a draft PR so I can note the changes I made to your version in case it causes confusion.

1. Integrate create.scale.bar function into SRCGrob by adding 2 params: scale.bar = <logical> and scale.bar.coords = c(left.x, top.y)
2. Add function to call create.scale.bar for each y axis defined by the user
3. Add helper function to pick a scale bar size (get.scale.bar.length) and to take the most common values in the tree column to determine the scale bar colour, line type and line width
4. Removed visual.length param from the create.scale.bar function so everything is defined relative to the scale.length
5. Units are defined within the function so that users don't have to worry about it
6. main and label fontsize are parametrized using cex to standardize with the rest of the package.

[whelena]

The force push is to remove a merge commit that committed unrelated files

[whelena]

@dan-knight I'd recommend running a few fuzz tests to evaluate the robustness of the scalebars with varying axis values. I tested with two edges using different scales, but it would be helpful to test on scales that differ by a few orders of magnitude.

[dan-knight]

Looks good! The separate viewport approach is ideal in my opinion. We may even want to refactor some other code to use this in future. Anyway, looks great. Most common value is a good default. We can even add the option to specify the scalebar style in future.

Have we thought about what might happen if someone wants one y-axis and one scalebar? Am I right that this code would support that as written?

[whelena]

Have we thought about what might happen if someone wants one y-axis and one scalebar? Am I right that this code would support that as written?

It wont support that because the current add.axes and add.scale.bar function takes both scales/lengths in make.clone.tree.grobs. To implement your suggestion we need to generalise the processing of each length, but for now they're always processed together I believe.