Feature: Clarify and handle Unicode combining and joiner characters, focusing on...

Feature: Clarify and handle Unicode combining and joiner characters, focusing on FSS Read.

One of the types of breaking changes and features that I allow are in regards to Unicode and following its standards.
I was never really sure how I was going to handle special cases, such as combining and joiner characters.
That has now changed and as of this change I now have declared the behavior.

This, unfortunately, resulted in a lot of changes and behavioral changes.
I have decided that making some breaking changes is the route to go.

One of my goals with this massive change set is to try to reduce how often I read the combining and joining characters.
There is going to be some performance hit but hopefully I have kept it to a minimal.

The crux of the problem is that the combining and joiner characters are after the character being changed rather than before.
That means that for every character being processed the code has to then go past it and check for a combining character.

I've noticed that most software does not handle combining characters and joiner characters following an end of line character.
I was going to treat this just like any other case but given the consistent way in which this is ignored I have decided to ignore combining and joiner characters specifically for end of lines `\n` (U+000A).

The specifications have been updated.
I do note that I need to clean them up at some future date.

I have decided to only focus on reading (**FSS Read**) given the size of this change.
The write code will be updated following this.
This change set is just too large as it is.

This change set did have some huge benefits such as exposing and helping me solve existing bugs and logic flaws.
Several of those changes have been extracted and committed separately, such as the "Bugfix: Fix invalid FSS Read unit test expectations.
" changes.

Another major change is in my commit and branching behavior.
In the distant past I had some data lost and lost a lot of work.
My immediate solution was to just push everything asap.
All in one branch.
All together.
Incomplete work is prefixed with "Progress:" to represent "work in progress".
This can get messy.

Switching to branching where I keep using "Progress:" will allow for me to manage the code as work in progress but then merge it in a cleaner manner.
Thus this massive commit.

The following are my notes collected from various commits in the separate progress branch.

Have to add is_combining functions to detect combining for the purpose of FSS processing.

Skip past initial place holders in the skip functions.

The initial combining returns `F_complete_not_utf_start` only for combining at the start.
This should be then handled as a combining.

Add a new feature via additional functions for explicitly checking for joiner characters.
These joiner characters are not the same as combining characters.

This requires various build settings, like stand alone builds, to be updated with one of the following source files added:
```
  fll/level_0/private-utf_joiner.c
  level_0/private-utf_joiner.c
  private-utf_joiner.c
```

This requires various `config.h` files to now support handling of:
```
  #define _di_f_utf_character_is_joiner_
  #define _di_f_utf_is_joiner_
```

I had the option of either adding this and not exposing it through the **API** or exposing it through the **API**.
Exposing it through the **API** causes this to be a new feature (which I really want to avoid in general).
However, if the code is going to be added (because it is necessary and fixes some bugs), then it makes more sense to just expose it through the **API**.

This also fixes incidental missing `_di*_` in some cases.

The combining combines into what is effectively a graph character.
Treat the joiner characters the same, even though one can join two non-printing characters.
New lines must ignore joiners (I have seen this as the standard behavior by a lot of software and decided to go with that to avoid problems).
The `is_combining`, `is_joiner`, and `is_combining_joiner` are new features added to help solve these problems.

I didn't want to add a cost of auto-checking every character after the first.
This means that I cannot have the `is_space`, `is_graph`, or other such functions automate this.
Therefore, the logic must be changed to check for these spaces.
The code will become more complex but this will not incur as much of a performance cost compared to checking each character 2x+ times.
I also decided not to continue on after the first combining and joiner characters.
The combining already makes something a graph.
The joiner requires more searched and is highly subjective.
Therefore, make life easier and just treat all joiners as graph-making for the purposes of processing and syntax.

Fix problem inn tests where its failing due to `getline()` reaching the end of the line.
If the EOL is reached, then the loop must end.

The `f_fss_skip_past_combining()` is replaced with `f_fss_skip_past_combining_joiner()`.

The `f_fss_seek_to_eol()` returns `F_okay_eol`.
Check that instead of doing a buffer string character comparison where possible.

Improve some condition block logic regarding breaks, returns, and continues.

Change some of the status error checking to reduce return statements.
I have probably flip flopped on this problem numerous times.
Looking into how compilers and CPUs like to optimize things, I believe that reducing the return statements will be of benefit vs the probably cleaner immediate returns.
This can only be done when it is clear and when the status code being returned (or any state) is identical between calls.

It seems that editors make it difficult to add and manipulate combining characters.
It is possible my test files have lost combining characters without my awareness.
I used commands like the following to help generate some combining characters:

```sh
echo "first valid.$(utf8 -cB U+0301)" >> basic-combining_read.txt

echo -e "  not a valid list{$(utf8 -cB U+0301)\n}" >> extended_list-combining_read.txt
```
Work on basic list combining tests, changing test strategy.

The previous strategies that I used were only doing a file of only **Objects** and files of only **Contents**.
This worked well for simple things.
This ideally better allowed for more isolated unit tests.

However, it is easier to write and follow tests of a complete **FSS** file.
This means doing both the **Object** and **Content** tests in the same unit test (despite being separate functions).
This provides more accurate checks, better testing, and as mentioned easier to write and follow test files.

I discovered that copying the file with the combining character at the start of the line (U+0301) causes a space to be added.
I have to then manually recreate the file and use my `utf8` program to regenerate the correct test data:
```sh
utf8 -cB U+0301 >> test.txt
```

I decided that I needed to expand the `f_fss_skip_past_space()` into `f_fss_skip_past_space_previous()` to expose the `previous` position variable to the caller.
I must avoid breaking the **API**/**ABI**, so `f_fss_skip_past_space()` is not changed.
This should simplify the embedded read functions.

Fix documentation, adding "Must not be NULL." where it is missing.

The man pages will need to be re-generated more than likely.
Just copy the `f_fss_skip_past_space()` man page and update it manually for now.

Add missing `_di_f_utf_is_zero_width_` check on `private_f_utf_character_is_joiner()`.

Redesign the FSS identify functions.

Always reset the original used length on error.

Reduce the number of return statements.

Add a check for the combining joiner characters after the `#`.

Remove inaccurate comment about depending on `f_utf_is_combining()` from parse function.

Utilize the `f_state_t` locally to perform the necessary operations.
This is not exposed to the caller to prevent **API** and **ABI** breakage.
Future versions of **FLL** (0.9+) are expected to pass the state via the function parameter.

Switch to the new practice of using flags to manage special internal states.
This no longer guesses success based on `ids.used` being non-zero.
Using the internal flags allows accurate handling.

Add comments to functions that need `f_state_t` so that future version of **FLL** can properly handle.

Rename `start` to `line_start` to be more consistent with other functions.
The `line_start` is also more unique.
This makes it easier to search.

Switch to `fll_flags` from `found_data` for managing flags within a function.

Handle basic list combining/joiner at start and fix unit test.

For lists, if the start of a line is a combining/joiner, then it must be treated as Content even if it would otherwise be a valid Object on that line.

The unit test actually has to handle when `F_okay_eos` or `F_okay_stop` is returned on content read.
The basic list doesn't know if the content is a valid object or not.
It can be assumed, but the function does not do this.

The caller must handle incrementing found.used when either `F_okay_eos` or `F_okay_stop` is returned.
Update the comment on this as well.

Properly verify that `newline_last` is in fact a new line by checking it against the `begin` position.
The basic list already has `begin`, but extended list has `begin` added to perform this check.