Refactor Merge Codes API

Right now, to completely add a merge code, you need to add a filter at two places:

First, you filter the button dropdown: https://github.com/gocodebox/lifterlms/blob/master/includes/admin/llms.functions.admin.php#L143

Then you filter the actual search-replace key-value pairs here:

https://github.com/gocodebox/lifterlms/blob/master/includes/certificates/class.llms.certificate.user.php#L134

So, the primary objective is to have one reference for merge codes that can be filtered in one go.

Additionally, we could have a merge code API similar to the erstwhile Metabox API of WordPress where you could possibly add a merge code:

```php
llms_add_mergecode( $code, $type, $replacement_function );
llms_remove_mergecode( $code, $type );
llms_update_mergecode( $code, $type, $replacement_function );
```
where
* `$code` = string inside `{` and `}`
* `$type` = the content type, `'certificate'`/`'email'`/`'all'`
* `$replacement_function` = the function that will be called and will return the actual text/html to replace the merge code. This will receive the current context object as a parameter, i.e. an instance of LLMS_Certificate_User in case of a certificate and of LLMS_Email_Engagement in case of an email. If empty, it will just be processed by core. If core doesn't have an internal handling mechanism, it'll throw a `_doing_it_wrong()` error similar to this: https://github.com/WordPress/WordPress/blob/master/wp-includes/shortcodes.php#L301

and create additional wrappers that just call core functions

```php
llms_add_certificate_mergecode( $code, $replacement_function );
llms_remove_certificate_mergecode( $code );
llms_update_certificate_mergecode( $code, $replacement_function );

llms_add_email_mergecode( $code, $replacement_function );
llms_remove_email_mergecode( $code );
llms_update_email_mergecode( $code, $replacement_function );
```

The callbacks would receive all the parameters available in the current filters. Empty replacement callbacks will be understood by the API to be handled internally (as it is now) and can be replaced with custom code far more easily, I feel.