Refactor options

[oubiwann]

Right now, options and their defaults are defined in the include file. These are accessed via the loise-opts module. Additionally, various modules may set up their own options, usually defined at the top of the module in an options function.

We need to make sure that the library is still usable for those not wishing to use the gen_server and just want access to the raw functions. It makes sense for the various modules (png, egd, ascii, perlin, simplex, etc.) to continue using loise-opts and the various defaults.

With that being said, now that we have state management (see #64), we can:

1. Move module-specific values / functions out of include/options.lfe and into their respective modules of interest and convert proplists to maps
2. Convert include/options.lfe to a module, moving it to something like src/loise-defaults.lfe
3. Convert proplists to maps in src/loise-defaults.lfe
4. Initialise state data with all the default options, data, etc., from src/loise-defaults.lfe -- avoid nested maps as much as possible
5. Provide a set of functions for getting/setting options data in the gen_server state
6. Update loise-opts to get the state data and extract value for key
7. Find and convert any calls using the old include file and proplists

Depends upon

• Support centralised, long-running state data #64

[oubiwann]

Now I'm second-guessing (third-guessing, actually) myself: Maybe we DO want to make all use of this library via the application and the state management of the gen_server? It would certainly simplify things by unifying the approach to options across all modules with no exceptions ...

[oubiwann]

So the reason include/options.lfe was created, was due to multiple modules needing access to the same data. If we pre-populate the gen_server with all the defaults and then define overrides in the modules that need to do the over-riding, then we can:

• ditch the entire include/options.lfe file
• make everyone use the loise app and the gen_server (however implicitly)
• go back to the idea of updating loise-opts to use data in the gen_server
• still allow for manual overrides via an options arg to all the key API functions, so that unit testing is still possible

[oubiwann]

If all the options and related data go into state, it would be nice to have easy access to each value (a la memcache), so I was thinking about refactoring these to be values stored as map keys.

A quick googling turned up this gem: Refactoring Erlang programs with regards to energy efficiency.

Sold.

I'll be re-editing the ticket description to take this into account.