Cornform to the go coding style by using the `gofmt`
tool to format the code.
This makes the code more "readable" and "maintanable".

Signed-off-by: Gekko Wrld <[email protected]>

The builtins are now in their own package.
This is to ensure extendable functions as opposed
to the previous method which they were in a "fixed" array.

Accessing the functions still uses an array as before.
This may be fixed to use a better way of accesing the
builtins but that will be done later.

Signed-off-by: Gekko Wrld <[email protected]>

Now the basic code that does basic find and replace has been finalized.

The following have yet to be implemented:

- No type checks are done, anything is printed.
- Only two types are supported
- No error is raised on incorrect values.

Other buitins have been moved to another file to create room to extend the `Andika` function.
This is intended to other builtins.

Signed-off-by: Gekko Wrld <[email protected]>

Signed-off-by: Gekko Wrld <[email protected]>

Now types are checked before appending to the 'new string'.
The '%' is truncated before being printed even if the syntax
turns out to be wrong.

An array is used to keep the type and subsequently checked against.
This is ineffective speed and perfomance wise.
A better solution _may be found_ in the future though.

>> No error handling yet

Signed-off-by: Gekko Wrld <[email protected]>

Now the code can handle gracefully:

- boolean
- arrays

Error handling has been enhanced to acceptable level (whatever that is).
Type mismatch is now reported appropriately.
If there is a mismatch in format specifiers to the actual arguments, then an
error is raised.
This only happens if the format specifiers are more than the passed arguments.
This doesn't apply the other way round.
This is consistent with how C handles this same situation in lax situation
(not tested in strict and golang though).

Changed the allowed specifiers to match their swahili names, making it easier
for swahili learners to pick up the specifiers.
This can be reverted though as it is mostly convention and not hard rules.

Code comments have been included to try and break down the code logic.
Repetetive part(s) have only been explained once.
This is to help maintainers and developers skim through the logic with the
help of the comments and understand it.
I know that this doensn't substitute clean readable code but it sure does help.

Format specifiers:

- %n -> Nambari
- %t -> Tungo (ama neno)
- %b -> Buliani (kweli, sikweli)
- %s -> Safu (ama orodha)

Signed-off-by: Gekko Wrld <[email protected]>

Previous implementation used case to match the format to its implementation.
Now it uses a map to do the matching.
This method has a couple of upsides:

- Now Flags can be handled easily
- The formats supported can be changed without logic change
- The 'main' function doesn't grow long with more implementations
- Each format can be treated as its own entity

Downsides:

- More time is spent on matching than previous implementation.
- More boiler plate code (not that much but adds up)
- `if` is slower than `case` (in some cases :) though)

Signed-off-by: Gekko Wrld <[email protected]>

Now flags infrastructure has been set up fully.
Addition of flags can be done now in few simple modifications.
For now only the following flags have been implemented:

- '+': Add a preceding '+' in integer values.
- '.': Add a predefined number of zeroes to float (DESIMALI)
- '!': Convert to uppercase the string passed (should be removed in the future).

The above implementated flags are just for demonstration of the flags
feature and not a concreate impelementation.

'%d' Have been added to the list of supported flags.
The flags represents "DESIMALI" type (e.g 2.4)

Error reporting is still not at par but good enough to nudge the user
in the right direction, but %.12 for example doesn't report any error.

The code still doesn't actually follow the DRY principle.
A lot of code is repeated.
Not sure if this is the biggest concern as of now.

Example usage as of now:

>>> andika('Habari %!t\n', 'nuru')
Habari NURU

>>> andika('%+.5d\n', 2.3)
+2.30000

If the flag is not known they it is silently ignored (the same as in golang (partly though)).
If the syntax is messed up, then undefined there will be undefied behaviour:
e.g:

>>> andika('%#.2_3d\n', 2.4)
2.40

This may or may not be the desired behaviour but the best that can be done (as of now).

NOTE:
Now andika() doesn't add an extra '\n' to the end of strings.
This **may** break the previous implementations.
This only happens if the first argument is a string, else the previous
implementation still aplies.

Signed-off-by: Gekko Wrld <[email protected]>

The Functions have been simplified.
A loop over slices have been converted into a map.

Flags are now resolved and the results passed to the functions
directly.
This reduces the boiler plate that was there before.
Conversion to int64 then to int has been simplified to just
an int.

An error is returned if the string ends before any format
specifier is found e.g

>>> andika('%4', 3.4)
Kosa: Siwezi kupata fomati inayofaa

The 'substitution' array `must` be equal to the 'real' array

>>> andika('Habari %t uko na miaka %n\n', 'Hana')
Kosa: Safu mbadala ni chini ya safu halisi

>>> andika('Habari %t uko na miaka %n\n', 'Hana', 21, ['a'])
Kosa: Safu halisi ni chini ya safu mbadala

Signed-off-by: Gekko Wrld <[email protected]>