RFC: handling of indicators in Marc21

If I understand it correctly, the Marc21 format allows for arbitrary indicators, addressing the usecases mentioned by @fjorba. This seems a definite improvement compared to Invenio 1.x.

For illustrative purposes I'll just use Marc `100` below, however, Marc has several fields where these issues apply as well.

If I understood the schema correctly, however, each marc field gets mapped to a JSON internal name. So, e.g. a field like `100__` gets mapped to `main_entry_personal_name`. Similarly, `1000_`, `1001_`, `1003_` get mapped to `main_entry_personal_name` as well, so all author personal names end up in the same JSON field. Again this addresses nicely the usecase of @fjorba as finally all authors regardless of the indicators get indexed and displayed as behind the ingestion only `main_entry_personal_name` is used.

In discussions with @martinkoehler we now wondered about dissemnation and probably indexing issues from there.

Say, I ingest Marc21 records that are using `1001_`. In Marc-language this refers to `$a` to store `Surename, Forename`. So the `1_` gives semantic introducing the concepts of Surename and Forename and define how they should be extracted.

```
100 1_ $aAdams, Henry
```

Now I ingest from another Marc source, and I get `1000_`. Here the 0 signifies, that the name in `$a` is a forename. The cannonical example at LoC being

```
100 0_ $aJohn $cthe Baptist, Saint
```

Sidenote to @martinkoehler: from the examples to `0_` it is clear, that this does not refer to a storage like _Henry Adams_ compared to `1_` _Adams, Henry_, but that it is indeed meant for name entities that consist of a forename only, like e.g. popes, saints or artists names.

In this discussion we also came to the point that it would be possible in principle to treat `1_` programatically as "split the name at `,` to the concepts of forename and surename and store them in two JSON fields. We were not clear if this is intended. It could address the dissemination issue mentioned below.

Another case is `1003_`:

```
100 3_ $aFarquhar family
```

Where you do not have a concept of _forename_ / _surename_ but the concept of _family name_. (Note: I'd have to check if RDA would not drop the _family_ in the above, it is clearly expressed in `3_` already can be a left over from ISBD in the AACR. At least I'd prefer to drop it.)

For indexing, one can argue that in the word index for names it might be no issue to treat them all alike. Regardless what you search is, _Adams, Henry_ or _Heny Adams_ the word index will take care of it probably treating the `,` as an unsignificant character. It might come up in the phrase index however, at least if one has a mixed storage (say one `100__$aHenry Adams`).

Some thoughts on this?

The second point and actually the main concerns arrise from reexporting to Marc. If `1001_` is ingested one would suspect to get `1001_` back, right? If I understand it correctly, right now one would get `100__`, right? Given the semantics introduced by the indicators, ignoring This them would loose information effectively.

In the current system this would not happen at least not if one stores the ingestion format as is. And as all processes are working on the ingested format updates to the records would be processed properly and thus keep the format.

Any thoughts on this yet?