.a are the unix equivalent to .libs, so they could be static libs or dynamic ones (requiring a dll). IIRC, the one in code::blocks is meant to be for dynamic linking, just look at a huge codeblocks.dll in your C::B installation path.
Actually, the SDK is pretty clean in the sense of the sources (usually very tidy and easy to understand - although theres a lack of comments), but the structure is a little bit unclean, since its not a SDK framework in the usual way. You see, when building a plugin, you link the required C::B library and the WxWidgets ones, but then you include the headers that you require yourself. Theres no single .h or a couple like in most plugin frameworks, but youll usually want to check at \src\sdk folder to see what you need.
The best thing to do is to check out the sources of the already existing plugins, to watch the structure and the common functions and classes they use, like the ones to get a pointer to the editor, to the active project/workspace, to save/load pluging setting and else.
To clarify a little bit, what I meant with the last couple of paragraphs is that C::B's SDK (leave aside the fact its an open source app) gives you -almost?- full control over the app, as it exposes most of the set of functions available to the main app itself to you, while in other plugin frameworks usually you only have a little set of functions to deal with, and you have a very reduced power in the sense of what you can do with the app through a plugin.
