[performance] A lot of CPU time consumed by accesses to `buf.Settings` map

CPU profiling via micro -profile shows that among the CPU time consumed by micro, a large fraction of time is usually spent in Go map accesses, e.g. in runtime.mapaccess1_faststr() and runtime.mapaccess2_faststr().

Most probably most of those map accesses are accesses to a buffer's Settings map. Micro's code, including such frequently called parts as displayBuffer(), is full of things like if b.Settings["diffgutter"].(bool). If we convert all those map accesses to simple struct field accesses (e.g. b.diffgutter), it should work much faster. (And we may still keep the map representation as well, e.g. for compatibility with plugins, just not use it inside micro itself all the time.)

Commit hash: 828871ac
OS: any
Terminal: any

Start with CPU profiling and the frequently called displayBuffer() path, then trace the b.Settings accesses described in the issue. Identify the relevant buffer settings and determine how to replace internal hot-path map lookups while retaining the map representation for plugin compatibility. Done means profiling shows reduced map-access CPU time without breaking existing settings behavior.