Remove String.format from logger calls to improve performance

[Alexjsenn]

Fixes #358
There are two or three statements where I left the String.format call because they had several arguments, and it probably doesn't make sense to create functions for that exact number of objects in cjfr-core.

[andrewazores]

they had several arguments, and it probably doesn't make sense to create functions for that exact number of objects in cjfr-core.

varargs? I believe the documentation specifies that this is how SLF4J does it - there are logger.log(String msg), logger.log(String msg, Object a), logger.log(String msg, Object a, Object b), and logger.log(String msg, Object... args) methods defined. We can do the same.

[Alexjsenn]

they had several arguments, and it probably doesn't make sense to create functions for that exact number of objects in cjfr-core.

varargs? I believe the documentation specifies that this is how SLF4J does it - there are logger.log(String msg), logger.log(String msg, Object a), logger.log(String msg, Object a, Object b), and logger.log(String msg, Object... args) methods defined. We can do the same.

Should I add these methods for all of the logger message types even though some may not be used?

[andrewazores]

They may not be used right now... IMO it only makes sense to make all of them consistent that way.

[Alexjsenn]

yes, it makes sense, I added all the methods in cjfr-core, and changed the last string.format calls.

[andrewazores]

Looks good. I manually rebased this and tested it myself and everything seems to continue working as expected. Please rebase this PR and I'll merge it.