WIP: Added arguments for toolbar for more visual control

@ChrisBeaumont - I was playing around with the toolbar parameters because for a standalone tool, the buttons could be made larger, and I was wondering whether - if we want to start exposing some of these items for users to build tools with - we should avoid hard-coding some of the values (e.g. icon size). In fact, for glue itself, I could see benefits to having things like icon size be a globally configurable value. So here are some possibilities (and the present PR is only meant to start discussion, it's not necessarily my preferred solution):

1. We introduce global settings for icon size, spacing, minimum toolbar height, and other values inside glue. The nice thing about this is it makes it possible for glue to have a 'preferences' pane where users e.g. with visual difficulties could make icons larger.

2. We add more arguments like the present PR in the ``__init__`` for people building other tools. However, this is only useful if I can access the toolbar's init - that is, if I create an ImageWidget I don't directly have control over all the arguments passed to the toolbar, and we don't want to add all these arguments to the ImageWidget (and other Widgets too).

3. We add settable properties with clear and documented names on various widgets. For example here we would create ``icon_size``, ``icon_spacing``, and so on, and then make sure we document these. This means that even if I create an ImageWidget, I can then set those properties to what I want. Of course, I can already do that but it was not easy to find the name of the existing setter methods to do it, so the last possibility is:

4. Better document how users can modify properties of widgets, but don't add any new properties.

Despite 4 being possible, I think that 3 would be valuable because for setting e.g. icon size it's not as simple as passing an int to that function, so if we can provide a simple property that hides away the ``QSize`` stuff, it would be easier.

Writing this out has helped me think about it more, and at the moment I would favor implementing 1 for some things that are general enough, and then also implementing 3 for those and other more specific parameters. Implementing 3 also means we get to control the content of the docstring for those parameters. We can then add an API section that shows just the properties we added, not all the inherited Qt properties, which will keep the API docs simple.

What do you think about these ideas? If we agree on the approach of 1 + 3, I can try and do that in this PR instead of what I have currently.