Alviss

Changed

- Stubber now has an option to only "export" the resulting "Final" stub
class and keeping all the other stubs "private" and this option is True by
default (they don't really need to be public)
- You can now give the resulting "Final" config stub a custom name
- You can also give the "Final" config stub an empty string for a name which
will simply omit generating it (for custom/complex composition of stubs
later on if people want)
- All stubs now also inherit from `dict` because any attribute in
`BaseConfig` that's a Map (and thus has a stub class) will also behave as
a `dict` (even if `Empty`)

Fixed

- Stubber now appends an underscore to stubs with Python reserved keywords
like `class` and `def` etc.
- The `BaseConfig` object now also spots attribute fetching of those
keywords with an appended underscore and fetches the correct attribute
nevertheless.

Added

- Stub generators from descriptor config files where you structure out your
config file and give each value the Python type you expect the config to
yield in order to generate type-hinting stub-classes that match the structure
of your config file(s).
- CLI commands for running the stub generation: `alviss-stubber`
- CLI commands for running the config rendering: `alviss-render`
- A bunch of Alviss specific Error Exceptions that are raised e.g.
when files aren't found or when Fidelius is required but isn't installed

Changed

- The rendering of static single file configs from Alviss config files and
expressions has now been moved into its own sub-module with a standard API

Added

- A way to make evaluating environment variables require a value to be found by
appending `!=` to the end of the expression like so `${__ENV__:API_KEY!=}`.
Missing values will trigger a `ValueError` raised when loading config files.

Added

- Fidelius mode - Alviss now reads the `ALVISS_FIDELIUS_MODE` environment
variable to determine one of these Fidelius modes available:
- `ON_DEMAND` (**default**): Fidelius is only ever loaded (i.e. an import is
attempted) if fidelius expressions (`__FID__`) are encountered when reading
a config
- `ENABLED`: Alviss tries to import fidelius on startup and raises an
`ImportError` if it fails
- `DISABLED`: All fidelius expressions (`__FID__`) are simply ignored and
left unparsed
- `SUBSTITUTE_ENV`: All fidelius expressions (`__FID__`) are treated as if
they are environment variable expressions (`__ENV__`)
- `MOCK`: Fidelius will be initialised using its mock implementation,
which uses a singleton in-memory datastore, making this useful for testing
- Error reporting on the keys that have Fidelius tags in them in case of a
Fidelius related error _(like access problems or if fidelius is not installed)_
- Fidelius can now grab config values from the config files Alviss is
reading via the `__fidelius__` special key (e.g. `ALVISS_FIDELIUS_MODE`
and any `kwargs` that `AwsParamStoreRepo` takes.

Changed

- Migrated the project from our internal repos to Github and Pypi
- Alviss now ships by default without [fidelius](https://pypi.org/project/fidelius/)
support and runs in `ALVISS_FIDELIUS_MODE=ON_DEMAND` and this only tries
to import fidelius if a `__FID__` expression is encountered
- Installing Alviss with built in fidelius support can still be done via
`pip install alviss[fidelius]` plus all the `boto3` stuff and such
- Bumped the `fidelius` version to 1.0.0 so now all the new environment
variables available in that version can be used to configure fidelius in
Alviss, e.g. by setting `FIDELIUS_AWS_ENDPOINT_URL` to point to a
[LocalStack](https://github.com/localstack/localstack) container for testing
and/or development.

Fixed

- An issue where the default values of environment variables could not
contain any whitespaces (like a simple space)

Fixed

- Issue where Fidelius expressions were being evaluated by default when calling `render_load`

Added

- Automatic parsing of Fidelius expressions `{$__FID__:...}`