Separate implementation from specific utilizations

This package hard for me to read. There's code that utilizes the package, which I would expect to find in a user's configuration, mixed together with the implementation. It makes the implementation hard to follow.

Some of the custom variables make it clear that this package does a lot by default. That's not great with downloading it intent to just create some custom special blocks without introducing a lot of unintended behavior for blocks already used in org.

I almost want to rewrite this with the following contents and structure:

1. implement the special block macro for defining new blocks
2. move each block to a file that contains both its specialized supporting Elisp and the block definition
3. shared Elisp definitions that are shared but only support block definitions

Rather than using customize to determine if a block would be included, as a user, I would simply load them or not load them or define a list of names to be loaded.

On the README, we need simple and sweet:
1. define a block type
2. how to write the block in org
3. a link to the tests, where the rest of "basic" examples should live, demonstrating the correlation between block definitions, org input, and expected output

I just showed up wanting to support github admonitions in my READMEs. I can't actually determine how to do that from the README as the `o-` prefix looks like `read-symbol-shorthands` and a lot of the functions within the package seem to use the `org` prefix although they normally would belong to a prefix like `osbe-` etc. It just needs to not collide often with the rest of the ecosystem.

Blocks shipped with the package would go in `osbe-color.el` `osbe-latex` etc.

For now I can't adopt this package and will instead begin repackaging it to see if the minimal implementation is easy to scavenge.