Introduce preference for automatic ascii visualization of system

[mfherbst]

Follow-up to #121 to discuss ascii visualisation preferences. Ping @cortner @rkurchin @jgreener64 to get some opinions.

I personally find it quite convenient to automatically get this insight when working in the REPL or a notebook, but this may just be me. I also found it helps students ... but again I introduced it, so I'm biased.

Options in my opinion are:

• Don't do it, people have to do it by calling visualize_ascii manually each time. Pros: Clear what happens, least complexity; Cons: It's an extra function to learn for something where Julia has builtin mechanics.
• Use some preference to configure it, e.g. Just enable/disable, some threshold in terms of number of atoms (done right now) or some threshold in terms of "density" of atoms on the canvas (to avoid cluttered ascii art, which is useless); Pros: Everyone can do as they please, if properly documented with helper functions should be fairly intuitive; Cons: We have to agree on defaults because most people will not change them.

In fact there may even be some builtin show preferences in Julia one can use for the second point ... I vaguely remember that, but I have not checked.

Other thoughts ?

[rkurchin]

I personally haven't made much use of it, and have occasionally found it distracting, but can also imagine cases where it would be useful as you say. I would be fine with either option you describe.

[jgreener64]

I don't view systems enough in the REPL to have strong opinions on this.

[cortner]

I'm ok with either option. If we go with a settable default then I will obviously vote to have a slim display as the default.

[mfherbst]

Ok, I added the preferences. By default visualize_ascii will not be called.

[mfherbst]

If one of you gives your ok, I guess we can merge.

[rkurchin]

Generally LGTM, should for sure fix the one tiny typo, and if people want to discuss the minor potential ambiguity, we can, but I'm also okay just merging this as-is since it's not a huge deal

[rkurchin]

Is this basically good to go? I don't think it should clash with #130 AFAICT, so presumably once coverage issues are addressed, it can be merged? I might have some time to add those couple of tests this afternoon if you don't already have them locally or something...

[mfherbst]

No go ahead !