Custom fixed bit-level integer encoding schemes
## Context

99% of time binary formats use standard little-endian or big-endian encoding of integers. However, in some cases people choose much more intricate encoding schemes. Take EDID, for example: they frequently employ tricks like spreading 12-bit integers like that:

    |aaaa aaaa|bbbb bbbb|AAAA BBBB|

## Current solution

Obviously, it's "read these chunks manually and assemble it via an expression", i.e.:

```yaml
seq:
  - id: a_lo
    type: u1
  - id: b_lo
    type: u1
  - id: a_hi
    type: b4
  - id: b_hi
    type: b4
instances:
  a:
    value: (a_hi << 8) | a_lo
  b:
    value: (b_hi << 8) | a_lo
```

The problems with this:

* It looks ugly.
* It pollutes generated class with lots of unnecessary attributes (i.e. `a_lo`, `a_hi`, `b_lo`, `b_hi`, etc), which are ultimately not interesting at all for end-user. End-user cares only for `a` and `b`.
* It utilizes lazy instances, which, in reality, are never needed here, and effort put into laziness (i.e. checks and caching) is actually greater than just doing the calculations in the first place.
* What's even worse, it creates lots of unnecessary complexity that will hinder serialization efforts. In our current serialization solution, end-user would have to manually set up all 6 attributes in a compliant manner:

```java
obj.setA(a);
obj.setB(b);
obj.setALo(a & 0xff);
obj.setBLo(b & 0xff);
obj.setAHi(a >> 8);
obj.setBHi(b >> 8);
```

... only after that it will pass the validation and allow proper serialization.

## Proposed solution

Add `bits-for` specification. Example above would be thus rendered as:

```yaml
seq:
seq:
  - bits-for: a[0..7]
    type: u1
  - bits-for: b[0..7]
    type: u1
  - bits-for: a[8..11]
    type: b4
  - bits-for: b[8..11]
    type: b4
```

Note that there are no explicit `id` given to these elements — they would just use autogenerated ones (and not show up by default in any introspection). Expected generation result is something along the lines of:

```java
private long a;
private long b;

private void _read() {
    this._unnamed0 = this._io.readU1();
    this._unnamed1 = this._io.readU1();
    this._unnamed2 = this._io.readBitsInt(4);
    this._unnamed3 = this._io.readBitsInt(4);

    this.a = (this._unnamed2 << 8) | this._unnamed0;
    this.b = (this._unnamed3 << 8) | this._unnamed1;
}

// relevant getters for a() and b() are obviously generated too
```

## Catches & tricks

Obviously, all attributes mentioned in `bits-for` would be created as integers, probably as `CalcIntType`.

### When it's ok to access resulting integer?

The simplest solution is to just put final result calculations at the very bottom of `_read()`, but it's not always right. Consider this:

```yaml
seq:
  - bits-for: a[0..7]
    type: u1
  - id: foo
    size: 100500
  - bits-for: a[8..11]
    type: b4
  - id: bar
    type: b4
    if: a < 42 # <= this one requires calculation result earlier than end of _read()
```

And this is probably some erroneous condition:

```yaml
seq:
  - bits-for: a[0..7]
    type: u1
  - id: foo
    size: 100500
    if: a < 42 # <= `a` is not complete at this stage
  - bits-for: a[8..11]
    type: b4
```

The simplest way to get away with that is to leave it to end user to solve, and go with incremental value building, i.e.:

```java
private void _read() {
    this._unnamed0 = this._io.readU1();
    this.a |= this._unnamed0;
    this._unnamed1 = this._io.readU1();
    this.b |= this._unnamed0;
    this._unnamed2 = this._io.readBitsInt(4);
    this.a |= (this._unnamed2 << 8);
    this._unnamed3 = this._io.readBitsInt(4);
    this.b |= (this._unnamed3 << 8);
}
```

Better way is probably to check & detect these "premature access" and "accessed-before-end-of-read" situations and generate relevant code.

### General validation

It's very easy to mess up stuff by:

* `bits-for: a[0..7]` + `bits-for: a[5..9]` — overlapping the range
* `bits-for: a[7..3]` — wrong order
* `bits-for: a[0..7]` + `type: u2` — more bits than needed
* `bits-for: a[0..12]` + `type: b3` — less bits than needed
* `bits-for: a[0..7]` + `type: f4` — totally incompatible type
* `bits-for: a[0..7]` + `type: s1` — probably should be still treated as incompatible
* `bits-for: a[0..15]` + `size: 2` — probably too

### Signed stuff

Shouldn't be that hard to implement with something like:

```yaml
seq:
  - sign-for: a
    type: b1
  - bits-for: a[0..7]
    type: b7
```

But the catch is that there are several major formats for signs, i.e. -1 might be encoded as:

    1111_1111 (normal)
    1000_0001 (not inverted without double zeroes)
    1000_0000 (not inverted + no double zeroes)

So probably one should add something to cater for that too...

### Allowing arbitary exceptions for bit numbers

Technically, it would be possible to do stuff like that for parsing:

```yaml
seq:
  - id: start
    type: u1
  - id: stop
    type: u1
  - bits-for: a[start..stop]
    type: b3 # or b(stop - start + 1)
```

Although it won't be super easy to do serialization for that, and I don't really see much use case for such flexibility, so I propose to not allow that, at least until someone will ask for it.