More customizable themes

[simonhamp]

A variation of #7 that goes a little further.

I thought about it a lot and realised that even though I want to provide an opinionated base set of styles, it does make sense to make it all more configurable.

I really liked @svenluijten's approach of moving towards more objects and interfaces as this is clean and predictable.

Fonts and Backgrounds were the main targets. With this new approach, it's now possible for developers to use completely custom font and background classes simply by implementing the SimonHamp\TheOg\Interfaces\Font and SimonHamp\TheOg\Interfaces\Background interfaces respectively.

Specifically though, the differences to #7 are:

• Removing the Font enum altogether.
  Relying on a single font class per font ultimately feels cleaner and more flexible. Putting all the fonts we might add to the core of this package in a single enum could get messy.

  Using static methods as factories provides a similar API to the enum.

• Keeping the Background enum, but having it construct instances of a new Background class, rather than the enum itself implementing the interface.

  This allows for the best of all scenarios:

  1. Built-in backgrounds can easily be defined and used via the enum - the user of the package doesn't need to know the path to those files
  2. A custom background can be defined simply by passing the relevant path to a new instance of the SimonHamp\TheOg\Theme\Background class:

  use SimonHamp\TheOg\Theme\Background;
  
  (new Image)->background(new Background('/path/to/my/image.png'));

  3. For complete flexibility, the developer can implement the Interfaces\Background interface or extend the Theme\Background class and build some custom logic for handling their background

  With background images via URL already a part of the package, which also introduces background images as a cover image (in addition to the pre-existing intended to be used as repeating patterns), there may also be some opportunity in the future to consolidate how these different types of background are handled all into this single Background class.

In addition, this PR:

• Ditches the Layout enum
  This wasn't really adding any value and felt like it would only add a burden to maintainers to remember to update when we add more layouts.

  To set a layout, I think it's clear enough that a new instance of the desired layout should be passed to the image, e.g.:

  use SimonHamp\TheOg\Layout\Layouts\GitHubBasic;
  
  (new Image)->layout(new GitHubBasic)

• Type-hints the EncoderInterface on Image::save()
  This tightens the restriction on what kind of 'format' can be used when saving the rendered image to a file: if the user wants something other than a PNG, they must pass an instance of one of the Intervention\Image\Encoders

[svenluijten]

I'll take a closer look later today! But looks solid on first glance 👀

[svenluijten]

I'm personally not a fan of abstract classes, but that's an implementation detail. This would definitely be a nice addition to The OG! LGTM 👌

[simonhamp]

I know what you mean. They could just be more concrete base classes.

I may refactor those out at some point, now that we have pretty solid interfaces across the board.