Should we returns meaningful error or should we keep it simple, stupid?

Hello,

Instead of an empty list maybe we could return a Result of data. Where Result can contains an error type (like Luhn check error or length error) or a all good with data something like

```
enum ResultCode {
Ok,
LengthError, // card with 50 digits
ValidationAlgorithmError, // luhn fail
ImplementationError, // unkown card
etc...
}

class Result {
public ResultCode ResultCode { get; }
public CardType Card { get; }
}
```

This could be nice in the front-end to show message to the end user like "This card seems to be a visa be the length does not match. A visa should have 13 or 16 numbers."


Of course we wont handle the message, but this issue will provide the tool to unlock the feature to developers

Thoughts? Would it be useful?

cc @4gq @fighou @torendil

Review the current card-identification API and how it represents an unsuccessful result; the issue names no files, entry points, or tests. Determine the desired Result shape and error categories with the maintainers, then verify that callers can distinguish successful card data from validation and implementation errors.

Written by the indexing model from the issue text.